[Bug c/35045] New: gcc-4.3 generates wrong code on i386 with -O3

[Bug c/35045] New: gcc-4.3 generates wrong code on i386 with -O3

[aurelien at aurel32 dot net]

The attached code, coming from the GNU libc (test-ifloat.c and 
s_cacoshf.c) gives wrong results when compiled with gcc-4.3 and -O3. The
results are correct with gcc-4.3 and lower optimizations, or with gcc-4.2.

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian
4.3-20080127-1)


-- 
           Summary: gcc-4.3 generates wrong code on i386 with -O3
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3

[aurelien at aurel32 dot net]

------- Comment #1 from aurelien at aurel32 dot net  2008-01-31 22:52 -------
Created an attachment (id=15070)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15070&action=view)
Testcase


-- 


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

[Bug middle-end/35045] gcc-4.3 generates wrong code on i386 with -O3

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-31 22:55 -------
Does -fno-gcse-after-reload fix the miscompiling?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|major                       |normal
          Component|c                           |middle-end


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

[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3

[aurelien at aurel32 dot net]

------- Comment #3 from aurelien at aurel32 dot net  2008-01-31 22:58 -------
Oops, the bug actually exist on *i386*, not on x86_64. I used the value from my
main installation and not from my i386 chroot.

Here are the correct specs:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian
4.3-20080127-1)


-- 

aurelien at aurel32 dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major
          Component|middle-end                  |c
  GCC build triplet|x86_64-unknown-linux-gnu    |i486-pc-linux-gnu
   GCC host triplet|x86_64-unknown-linux-gnu    |i486-pc-linux-gnu
 GCC target triplet|x86_64-unknown-linux-gnu    |i486-pc-linux-gnu


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

[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3

[aurelien at aurel32 dot net]

------- Comment #4 from aurelien at aurel32 dot net  2008-01-31 22:59 -------
(In reply to comment #2)
> Does -fno-gcse-after-reload fix the miscompiling?
> 

Yes that fixes the problem.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-01 10:33 -------
Confirmed.  Fails with -O3 -mpc64 (it passes with -fno-gcse-after-reload and
also
with -ffloat-store)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
          Component|c                           |target
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
      Known to work|                            |4.2.3
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-01 10:33:25
               date|                            |
            Summary|gcc-4.3 generates wrong code|[4.3 Regression] gcc-4.3
                   |on i386 with -O3            |generates wrong code on i386
                   |                            |with -O3
   Target Milestone|---                         |4.3.0


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[ismail at pardus dot org dot tr]

------- Comment #6 from ismail at pardus dot org dot tr  2008-02-01 10:45 -------
Nice, this is what I was seeing all along. Shouldn't this be a P1 though?


-- 

ismail at pardus dot org dot tr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ismail at pardus dot org dot
                   |                            |tr


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-01 10:54 -------
gcse after reload removes the load imaginary part of the return value
(__complex__ float is returned in %eax/%edx pair):

@@ -274,12 +274,10 @@
        call    nanf
        fstps   -24(%ebp)
        movl    -24(%ebp), %ecx
-       movl    %ecx, -12(%ebp)
-       movl    %ecx, %eax
-       movl    -12(%ebp), %edx
        addl    $36, %esp
        popl    %ebx
        popl    %ebp
+       movl    %ecx, %eax
        ret

etc.

This is probably a DF and/or target issue.  The testcase can be simplified
to only call for example the first check_complex function in main().
It also fails with -O -fno-inline -fgcse-after-reload, mycacoshf is the
function that is miscompiled (as it returns a complex).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at gcc dot gnu dot
                   |                            |org, stevenb dot gcc at
                   |                            |gmail dot com, matz at gcc
                   |                            |dot gnu dot org


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[stevenb dot gcc at gmail dot com]

------- Comment #8 from stevenb dot gcc at gmail dot com  2008-02-01 11:51 -------
Subject: Re:  [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

I would say it is a target issue if the target return insn does not
mention that %edx is used.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[steven at gcc dot gnu dot org]

------- Comment #9 from steven at gcc dot gnu dot org  2008-02-01 11:53 -------
Mine to investigate.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-02-01 10:33:25         |2008-02-01 11:53:31
               date|                            |


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2008-02-01 11:58 -------
Reduced testcase:

extern __complex__ float clogf (__complex__ float);

__complex__ float
mycacoshf (__complex__ float x)
{
  __complex__ float res;
  res = clogf (x);

  /* We have to use the positive branch.  */
  if (__real__ res < 0.0)
    {
      res = -res; 
      asm ("" : : : "%ecx", "%ebx", "%esi", "%edi");
    }
  return res;
}

-fgcse-after-reload removes the load of the clobbered %edx (it's life
in the other path)


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2008-02-01 12:02 -------
Re comment #9 - after postreload there is only

(insn 62 61 40 4 test-cacoshf.c:16 (set (reg:SF 0 ax [ <result> ])
        (mem/c:SF (plus:SI (reg/f:SI 6 bp)
                (const_int -20 [0xffffffffffffffec])) [0 S4 A8])) 97 {*movsf_1}
(nil))

(insn 40 62 45 4 test-cacoshf.c:16 (set (reg:SF 1 dx [+4 ])
        (mem/c:SF (plus:SI (reg/f:SI 6 bp)
                (const_int -16 [0xfffffffffffffff0])) [0 res$imag+0 S4 A8])) 97
{*movsf_1} (nil))

(insn 45 40 56 4 test-cacoshf.c:16 (use (reg/i:SC 0 ax)) -1 (nil))
;; End of basic block 4 -> ( 1)
;; lr  out       0 [ax] 1 [dx] 6 [bp] 7 [sp] 20 [frame]


but (reg:SC ax) should include dx, right?


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2008-02-01 12:53 -------
Lets make this P1 until it is properly analyzed as eventually this also affects
functions returning DImode.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2008-02-01 13:04 -------
gcse-after-reload inserts

(insn 66 30 31 3 (set (reg:SF 1 dx [+4 ])
        (mem/c:SF (plus:SI (reg/f:SI 6 bp)
                (const_int -16 [0xfffffffffffffff0])) [0 res$imag+0 S4 A]

on the edge from bb3 to bb4, which looks correct.  This insn vanishes during
184r.dse2:

DCE: Deleting insn 66
deleting insn with uid = 66.


One problem may be that gcse doesn't update LIFE:

...
(insn 30 60 66 3 test-cacoshf.c:13 (parallel [
            (asm_operands/v ("") ("") 0 []
                 [] 1606)
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
            (clobber (reg:QI 5 di))
            (clobber (reg:QI 4 si))
            (clobber (reg:QI 3 bx))
            (clobber (reg:QI 2 cx))
        ]) -1 (nil))

(insn 66 30 31 3 (set (reg:SF 1 dx [+4 ])
        (mem/c:SF (plus:SI (reg/f:SI 6 bp)
                (const_int -16 [0xfffffffffffffff0])) [0 res$imag+0 S4 A8])) -1
(nil))
;; End of basic block 3 -> ( 4)
;; lr  out       6 [bp] 7 [sp] 9 [st(1)] 20 [frame]


lr out doesn't include dx.  Is gcse supposed to update lr out?


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2008-02-01 13:15 -------
Let's CC some x86 maintainers


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uros at gcc dot gnu dot org,
                   |                            |hubicka at gcc dot gnu dot
                   |                            |org


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[steven at gcc dot gnu dot org]

------- Comment #15 from steven at gcc dot gnu dot org  2008-02-01 13:19 -------
CCing half the world is not going to help anyone.

Try adding TODO_df_finish.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|stevenb dot gcc at gmail dot|
                   |com                         |


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2008-02-01 14:08 -------
The problem is that we retain

(insn 38 32 61 4 test-cacoshf.c:16 (clobber (reg/i:SC 0 ax)) -1 (nil))

after postreload and gcse rightfully assumes such clobbers are removed
(and hoists over them).  They are supposed to be removed by reload1.c:reload()
which does

  /* Make a pass over all the insns and delete all USEs which we inserted
     only to tag a REG_EQUAL note on them.  Remove all REG_DEAD and REG_UNUSED
     notes.  Delete all CLOBBER insns, except those that refer to the return
     value and the special mem:BLK CLOBBERs added to prevent the scheduler
     from misarranging variable-array code, and simplify (subreg (reg))
     operands.  Also remove all REG_RETVAL and REG_LIBCALL notes since they
     are no longer useful or accurate.  Strip and regenerate REG_INC notes
     that may have been moved around.  */

...
                && (!REG_P (XEXP (PATTERN (insn), 0))
                    || ! REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0)))))
          {
            delete_insn (insn);
            continue;
          }

where the exception for return value clobbers was added by rth with

r30401 | rth | 1999-11-05 01:35:10 +0100 (Fri, 05 Nov 1999) | 9 lines

        * function.c (diddle_return_value): New.
        (expand_function_end): Use it.
        * stmt.c (expand_null_return): Likewise.
        (expand_value_return): Likewise.

        * reg-stack.c (subst_stack_regs_pat): Handle clobbers at top-level.

        * reload1.c (reload): Don't remove return value clobbers.

seemingly as an optimization(?) with stmt.c:expand_null_return():

void
expand_null_return (void)
{
  /* If this function was declared to return a value, but we
     didn't, clobber the return registers so that they are not
     propagated live to the rest of the function.  */
  clobber_return_register ();


which doesn't make sense to me (_which_ rest of the function?).  Maybe
this refers to missed optimizations with the RTL inliner?

Removing this restriction from reload fixes this problem.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[stevenb dot gcc at gmail dot com]

------- Comment #18 from stevenb dot gcc at gmail dot com  2008-02-01 14:14 -------
Subject: Re:  [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

Why would we be calling expand_null_return to begin with, if there is
a proper return statement?


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2008-02-01 14:13 -------
Hm, it might be all due to the reg-stack.c hunk in rths patch:

+               /* A top-level clobber with no REG_DEAD, and no hard-regnum
+                  indicates an uninitialized value.  Because reload removed
+                  all other clobbers, this must be due to a function 
+                  returning without a value.  Load up a NaN.  */
...


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[rguenther at suse dot de]

------- Comment #19 from rguenther at suse dot de  2008-02-01 14:38 -------
Subject: Re:  [4.3 Regression] gcc-4.3 generates wrong code
 on i386 with -O3

On Fri, 1 Feb 2008, stevenb dot gcc at gmail dot com wrote:

> ------- Comment #18 from stevenb dot gcc at gmail dot com  2008-02-01 14:14 -------
> Subject: Re:  [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3
> 
> Why would we be calling expand_null_return to begin with, if there is
> a proper return statement?

No idea, we seem to add these clobbers unconditionally from
expand_function_end.

One fix is to teach postreload-gcse record_last_set_info about
the other parts of the (clobber (reg:SC ax)) as it currently
only sees ax.  Micha has a patch for this (gcse.c looks similarly
affected).

Richard.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

------- Comment #20 from matz at gcc dot gnu dot org  2008-02-01 14:40 -------
Created an attachment (id=15074)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15074&action=view)
patch for postreload-gcse

This fixes the oversight in postreload-gcse.c and this bug.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

------- Comment #21 from matz at gcc dot gnu dot org  2008-02-01 14:45 -------
GCSE itself might or might not be safe, I haven't yet gone through all paths.
But normally it enters only pseudo regs into the hash tables.  It does
remember invalidation of hard-regs, though, and that definitely is broken in
the same way.  The question is just, if it matters in the end, if it only
ever fiddles with instructions setting/using pseudos.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[stevenb dot gcc at gmail dot com]

------- Comment #22 from stevenb dot gcc at gmail dot com  2008-02-01 14:55 -------
Subject: Re:  [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

Could you retain the "          gcc_assert (HARD_REGISTER_P (x)); please?


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

------- Comment #23 from matz at gcc dot gnu dot org  2008-02-01 14:59 -------
I haven't removed it.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[debian-gcc at lists dot debian dot org]

------- Comment #24 from debian-gcc at lists dot debian dot org  2008-02-01 18:53 -------
please mention 35045 in the testcase and changelog entry (not 34054).

  Matthias


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

------- Comment #25 from matz at gcc dot gnu dot org  2008-02-02 15:01 -------
Subject: Bug 35045

Author: matz
Date: Sat Feb  2 15:00:57 2008
New Revision: 132071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132071
Log:
        PR target/35045
        * postreload-gcse.c (record_last_reg_set_info_regno): Renamed
        from record_last_reg_set_info.
        (record_last_reg_set_info): Take an RTX argument, iterate over all
        constituent hardregs.
        (record_last_set_info, record_opr_changes): Change calls to
        new signature or to record_last_reg_set_info_regno.

        * gcc.dg/pr35045.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr35045.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/postreload-gcse.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

------- Comment #26 from matz at gcc dot gnu dot org  2008-02-02 15:06 -------
Fixed in trunk.  Matthias: thanks for the hint with the bugnumber :-)


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[dominiq at lps dot ens dot fr]

------- Comment #27 from dominiq at lps dot ens dot fr  2008-02-03 08:41 -------
On i686-apple-darwin9, rev. 132071, gcc.dg/pr35045.c gives an ICE in 32 bit
mode :

/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/pr35045.c: In function 'mycacoshf':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/pr35045.c:26: error: can't find a
register in class 'GENERAL_REGS' while reloading 'asm'
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/pr35045.c:26: error: 'asm' operand has
impossible constraints

The ICE disappears with -m64.


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[ubizjak at gmail dot com]

------- Comment #28 from ubizjak at gmail dot com  2008-02-03 11:28 -------
(In reply to comment #27)
> On i686-apple-darwin9, rev. 132071, gcc.dg/pr35045.c gives an ICE in 32 bit
> mode :

Probably a -fpic issue.


-- 


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