User account creation filtered due to spam.
Here is a simple code :
unsigned int y;
*((unsigned int *)&foo)=0x40555555;
Note : Direct FP manipulation is required by my application as it needs to
perform conversion from a different FP encoding.
Straight compiling (gcc foo.c -o foo) gives the expected result :
However, compiling with the following flags give various results :
"gcc -O3 -march=pentium4 -fPIC foo.c foo"
Using gcc 3.3.4 with the same flags give :
Examination of the generated assembly indicate various cases :
Starting with 3.4.1 (comments are my own)
... prolog ...
movss (%ecx), %xmm0 Put *%ecx in MMX Reg 0
movl $1079334229, (%ecx) Put constant in *%ecx - UGH ! Backwards
subl $16, %esp
movss %xmm0, -8(%ebp) Save MMX Reg 0 in %ebp[-8]
cvttss2si %xmm0, %edx Convert Single Prec to Signed Int to %edx
movl %eax, (%esp)
movl %edx, 12(%esp)
... epilog ...
and now with gcc 3.3.4 :
... prolog ...
cvttss2si (%ecx), %eax Convert Single Prec float @%ecx to %eax
movl $1079334229, (%ecx) Put constant value@%ecx - Backwards !
movl %eax, 12(%esp)
movl %edx, (%esp)
... epilog ...
- No problem shows if -fPIC is not specified
- Tried -mfpmath=387 but didn't help
- -msse or -msse2 are also sufficient to trigger the problem
- with -march=pentium2 and no -msseX, the problem goes away
- Problem only shows at -O2 or better
I tried with
- gcc 3.3.4 from debian
- gcc 3.4.1 from debian
- gcc 3.4.1 from Mandrake
(haven't tried stock gcc - but I suspect I might be getting identical results
as I am getting similar results from different vendors).
Ah.. Another thing :
If the 'float' is initialised with a float constant directly
(i.e. "foo=3.3333", instead of filling in directly the IEEE hex representation
of the float through casting and indirections), no problem occurs, which could
mean (writing as I am thinking) a problem exists in the machine description
for SSE capable machines, leading the various insn shufflings to loose the
track of the variable state (forgetting that (int)foo is dependent on foo -
and this possibly happens because 'foo' is never an lvalue - although *&foo is)
You are violating C aliasing rules: *(unsigned int *)&foo.
Getting better results (at least consistent resuls) with a union.. (not sure
it'll fix my original problem though)..
It's still a bit annoying that if this is not a valid C construct (or an
undefined C constuct) that
- No warning or error is given at compile time
- Result is inconsistent
- gcc is producing senseless code (2 instructions in a row writing over the
same memory location and/or register)
Thanks anyway for looking into it :)
We do warn with -Wall (which turns on -Wstrict-aliasing).
Subject: RE: Implicit SSE/SSE2 FP code reordering in Placement Independent Code error (SSE/optimisation/PIC)
Thanks for the pointers, and sorry for the extra work.
I still have (what I believe) to be an SSE/SSE2 issue somewhere in my
program (which is raising SIGFPE while all FP traps are blocked), but I want
to get a testcase up and ready (unless I find all this to be an issue in the
code per-se) before I go at posting an eventual bug report.
Again, thank you for your time.
> -----Original Message-----
> From: pinskia at gcc dot gnu dot org
> Sent: Friday, September 10, 2004 5:53 PM
> To: email@example.com
> Subject: [Bug c/17394] Implicit SSE/SSE2 FP code reordering
> in Placement Independent Code error (SSE/optimisation/PIC)
> ------- Additional Comments From pinskia at gcc dot gnu dot
> org 2004-09-10 15:52 -------
> We do warn with -Wall (which turns on -Wstrict-aliasing).
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
Reopening to ...
Mark as a dup of bug 21920
*** This bug has been marked as a duplicate of 21920 ***