Mail Archives: cygwin/2004/04/28/00:03:26
Please forgive me if that's not the proper place for that report, i'm
trying here first as it's at least partially a cygwin problem :)
With an up to date cygwin environement i've built the latest release of
gcc/g++:
Reading specs from /usr/local/gcc/lib/gcc/i686-pc-cygwin/3.4.0/specs
Configured with: ../configure --prefix=/usr/local/gcc
--enable-languages=c,c++ --enable-threads=posix --with-system-zlib
--disable-nls --disable-shared --disable-win32-registry --verbose
--with-gcc --with-gnu-ld --with-gnu-as
Thread model: posix
gcc version 3.4.0
Building an app of mine (multithreaded) with something like -O3
-march=k8 the binary died with an illegal instruction. The offending
instruction was a 'movaps %xmm0, 0x40(%esp)' with an unaligned esp.
As that was on a secondary thread after some external calls (opengl and
so on) i thought it had to do with some cygwin/ABI issue or something.
After a day of struggling/web digging, i still had no clue.
And 1hour ago i got g++ to produce that sequence (same app, slightly
different compilation switches like -mfpmath=sse,387): 'xorps
0x435d7c,%xmm1'
That one is clearly wrong and doesn't have to do with stack alignment.
I've been trying to produce a test case, but miserably failed. That bad
code gen happens for the k8 & p4 targets at least and with pretty
default switches (ie -O3 -march=k8) and none fix it, tho i cannot test
if that also happens on anything else than cygwin. Take note that my app
doesn't generate sse1/2 on its own, it all comes from gcc.
I'm puzzled & surprised that nobody tripped that one earlier and i'd
apreciate any clue.
tbp
PS: i'm off list, plz cc
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -