from SJ/LJ exceptions to DWARF2. But the operating system
can't handle relocations to odd addresses. So I wonder if there is a
solution.
Cheers,
--
Vincent Rivière
fect, it
could also remember the number of bytes already pushed on the stack. So next
references to stack variables could be adjusted with the proper offset. This
way GCC would produce valid and optimal code.
--
Vincent Rivière
movel %sp@+,%d2
1c: 245fmoveal %sp@+,%a2
1e: 4e5eunlk %fp
20: 4e75rts
0022 :
22: 2f6f 0008 0004 movel %sp@(8),%sp@(4)
28: 2f6f 000c 0008 movel %sp@(12),%sp@(8)
2e: 60d0bras 0
Again this produces correct code, but it adds useless linkw/unlk
instructions. And moreover, it prevents the binding function to be inlined.
Any hints to solve this issue will be appreciated.
--
Vincent Rivière
le, buffer overflow, strict aliasing issue, or
maybe a GCC bug...
Since it is unlikely that this specific bug is in the standard GCC sources
(other people would have noticed), maybe it could be somewhere in the C
sources added for your NeXT configuration?
--
Vincent Rivière
cated line
to see what is there.
Also, looking at the preprocessor output may help.
Try this:
xgcc -E acos_test.c
Then search for acos to see if there is nothing wierd.
Good luck.
--
Vincent Rivière
does not support C99, I have just posted a patch to fix that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47672
--
Vincent Rivière
