SIGILL on Sparc

[Piotr Wyderski]

Hello,

I have a problem with a (big) C++ program compiled
with gcc 4.4.0 on a 64-bit Sparc.

Target: sparc-sun-solaris2.10

Configured with: /opt/sources/gnu/gcc-4.4.0/configure
--prefix=/opt/gnu/gcc-4.4.0 --with-local-prefix=/opt/gnu/gcc-4.4.0
--enable-threads=posix --with-cpu=ultrasparc3 --enable-tls=yes
--with-tune=ultrasparc3 --enable-languages=c,c++ --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --with-gmp=/opt/gnu/gmp-4.2.1
--with-mpfr=/opt/gnu/mpfr-2.4.1 --disable-nls

Thread model: posix

gcc version 4.4.0 (GCC)

The compiler generated the following code (debug version):

0xffffffff751407b4 <Functions+204>:     nop
0xffffffff751407b8 <Functions+208>:     ldx  [ %fp + 0x87f ], %o0
0xffffffff751407bc <Functions+212>:     clr  %o1
0xffffffff751407c0 <Functions+216>:     call  0xffffffff7543bc00
<_ZN6parser8internal9Functions11setCategoryENS0_11EH_CategoryE@plt>
0xffffffff751407c4 <Functions+220>:     nop
0xffffffff751407c8 <Functions+224>:     ta  5 <=== Here the SIGILL happens

The function SetCategory(v) returns void and simply assigns
the value of v to a class member, so there are no trap conditions.
TA, on the other hand, stands for "trap always", so the condition
code is unimportant anyway. Why has the trap instruction been generated?

Best regards
Piotr Wyderski