27 Aug
2014
27 Aug
'14
12:31 a.m.
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,
--
Slávek
27 Aug
27 Aug
1:46 a.m.
New subject: R: [trinity-devel] KOffice workaround for raspbian-wheezy
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
6:48 a.m.
New subject: [trinity-devel] R: [trinity-devel] KOffice workaround for raspbian-wheezy
On Wednesday 27 of August 2014 03:46:02 Michele Calgaro wrote:
I tried - still the same FTBFS with reference to a compiler bug.
Any other suggestions? :)
--
Slavek
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
12:06 p.m.
New subject: [trinity-devel] R: [trinity-devel] KOffice workaround for raspbian-wheezy
> 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
12:37 p.m.
New subject: [trinity-devel] R: [trinity-devel] KOffice workaround for raspbian-wheezy
Dne st 27. srpna 2014 Michele Calgaro napsal(a):
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.
--
Slavek
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? :)
3530
days inactive
3530
days old
4 comments
2 participants
participants (2)
-
Michele Calgaro -
Slávek Banko