| Summary: | Implicit SSE/SSE2 FP code reordering in Placement Independent Code error (SSE/optimisation/PIC) | ||
|---|---|---|---|
| Product: | gcc | Reporter: | ivan |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P2 | ||
| Version: | 3.4.1 | ||
| Target Milestone: | --- | ||
| Host: | i686-linux-gnu | Target: | i686-linux-gnu |
| Build: | i686-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
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) --Ivan You are violating C aliasing rules: *(unsigned int *)&foo. Ok.. 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 :) --Ivan 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.
--Ivan
> -----Original Message-----
> From: pinskia at gcc dot gnu dot org
> [mailto:gcc-bugzilla@gcc.gnu.org]
> Sent: Friday, September 10, 2004 5:53 PM
> To: ivan@vmfacility.fr
> 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).
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17394
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
Reopening to ... |
Here is a simple code : <testcase> #include <stdio.h> float foo; int main() { unsigned int y; *((unsigned int *)&foo)=0x40555555; y=(int)foo; printf("%g %d\n",foo,y); } </testcase> 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 : "3.3333 3" However, compiling with the following flags give various results : "gcc -O3 -march=pentium4 -fPIC foo.c foo" gives : "0 0" Using gcc 3.3.4 with the same flags give : "3.3333 0" 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) flds -8(%ebp) movl %edx, 12(%esp) fstpl 4(%esp) call printf@PLT ... 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) flds (%ecx) movl %edx, (%esp) fstpl 4(%esp) call printf@PLT ... epilog ... Notes - 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). Thanks, --Ivan