Hi all,
from the very beginning, when they were included builds for raspbian-wheezy, I watching FTBFS in KOffice with reference to a compiler bug. See:
/build/buildd/koffice-trinity-14.0.0-r313/./chalk/core/kis_exif_value.cc: In member function 'TQString ExifValue::toString(uint)': /build/buildd/koffice-trinity-14.0.0-r313/./chalk/core/kis_exif_value.cc:685:1: error: unrecognizable insn: (insn 676 675 677 19 (set (subreg:SI (reg:DI 378 [ D.20205_111->m_sbyte ]) 0) (sign_extend:SI (mem/s:QI (plus:SI (mult:SI (reg/v:SI 269 [ i ]) (const_int 8 [0x8])) (reg/f:SI 374 [ this_1(D)->m_value ])) [0 D.20205_111->m_sbyte+0 S1 A64]))) /usr/share/tqt3/include/ntqstring.h:949 -1 (nil)) /build/buildd/koffice-trinity-14.0.0-r313/./chalk/core/kis_exif_value.cc:685:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
Because in the last days Michele worked on fix build KOffice with Ruby 2.1 and libwpd-0.10 (good work Michele!), I devoted some time to explore the problem on Raspbian. I've isolated the problem and then created a workaround. Please see the attached patch.
What is your opinion? Can I push it?
Thanks,
from the very beginning, when they were included builds for raspbian-wheezy, I watching FTBFS in KOffice with reference to a compiler bug. See: What is your opinion? Can I push it?
Hi Slavek, the patch looks ok and quite simple. Nevertheless the compiler error sounds a little weird, I would expect a similar error to popup in many more places. By the way have you tried by forcing an explicit cast? Something like:
case EXIF_TYPE_SBYTE: return TQString("%1 ").arg( static_cast<TQ_INT8>(asExifNumber( i ).m_sbyte) );
It's a little "less invasive". If it doesn't work (hidden compiler mystery....), just go ahead and push your patch. Cheers Michele
On Wednesday 27 of August 2014 03:46:02 Michele Calgaro wrote:
from the very beginning, when they were included builds for raspbian-wheezy, I watching FTBFS in KOffice with reference to a compiler bug. See: What is your opinion? Can I push it?
Hi Slavek, the patch looks ok and quite simple. Nevertheless the compiler error sounds a little weird, I would expect a similar error to popup in many more places. By the way have you tried by forcing an explicit cast? Something like:
case EXIF_TYPE_SBYTE: return TQString("%1 ").arg( static_cast<TQ_INT8>(asExifNumber( i).m_sbyte) );
It's a little "less invasive". If it doesn't work (hidden compiler mystery....), just go ahead and push your patch. Cheers Michele
I tried - still the same FTBFS with reference to a compiler bug. Any other suggestions? :)
It's a little "less invasive". If it doesn't work (hidden compiler mystery....), just go ahead and push your patch. Cheers
I tried - still the same FTBFS with reference to a compiler bug. Any other suggestions? :)
Slavek, the problem is not in the C++ code, but clearly in the compiler. If you google a little you can see we are not the only one affected :) The problem is probably caused by the addition in: "[0 D.20205_111->m_sbyte+0 S1 A64]))" even though it is not clear to me why the compiler generate such code since I didn't see any addition in the C++ code. Since your patch works and it is quite simple, just push it. The comment in place will remind us of why the change was necessary.
Cheers Michele
Dne st 27. srpna 2014 Michele Calgaro napsal(a):
It's a little "less invasive". If it doesn't work (hidden compiler mystery....), just go ahead and push your patch. Cheers
I tried - still the same FTBFS with reference to a compiler bug. Any other suggestions? :)
Slavek, the problem is not in the C++ code, but clearly in the compiler. If you google a little you can see we are not the only one affected :) The problem is probably caused by the addition in: "[0 D.20205_111->m_sbyte+0 S1 A64]))" even though it is not clear to me why the compiler generate such code since I didn't see any addition in the C++ code. Since your patch works and it is quite simple, just push it. The comment in place will remind us of why the change was necessary.
Cheers Michele
Exactly so. Also, I've searched for informations. And I found the advice to change gcc to 4.7 or turn off O2 optimization. Both to me seemed as a more substantial intervention than a small simple patch from the initial mail.
Pushed to GIT in hash 5a8694bb.
-
Michele Calgaro -
Slávek Banko