[Bug target/25303] New: [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[Bug target/25303] New: [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[hjl at lucon dot org]

Gcc 4.0 20051113 and 4.120051207 miscompiled eon in SPEC CPU 2K with -O2. I got

Running Benchmarks
  Running 252.eon ref base o2 default
*** Miscompare of pixels_out.kajiya, see
/export/spec/src/2000/spec/benchspec/CINT2000/252.eon/run/00000002/pixels_out.kajiya.mis

x86-64 seems OK. Gcc 4.2 20051203 is OK.


-- 
           Summary: [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-07 20:59 -------
The last time I looked at eon failing on x86, it was due to excessive
precission for fp.  Yes FP in an int test but what ever.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-07 21:00 -------
Also I should note that it would fail the same way for 3.4, 3.3, and many older
compilers.

And if that is the case this is a dup of bug 323.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[hjl at lucon dot org]

------- Comment #3 from hjl at lucon dot org  2005-12-07 21:49 -------
It could be. After adding -ffast-math to gcc 4.1, eon is OK.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-08 00:49 -------
Can you try -ffloat-store or do the following:
On Linux/ix86 we use long double precision for evaluation of floating point
variables. This can lead to different values than the expected values. I'm
experimenting on the tests for cfg-branch with a small shared library that is
preloaded. 

The complete code is below, I compiled it with gcc -Wall -O2 -shared -o
libchange-precission.so change-precission.c and set LD_PRELOAD to this library. 

extern void change_precission (void) __attribute__ ((constructor));

void
change_precission (void)
{
  unsigned int cw = 0x27f;

  __asm__ volatile ("fldcw %0" :: "m" (*&cw));
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[hjl at lucon dot org]

------- Comment #5 from hjl at lucon dot org  2005-12-08 01:46 -------
-ffloat-store fixed eon for gcc 4.1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303

[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2005-12-08 01:47 -------
Then this is a dup of 323, closing as such.

*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303