--- 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:
--- 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
--- 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=gccview=revrev=132071
Log:
PR target/35045
* postreload-gcse.c
--- 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
--- 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
--- 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 @@
callnanf
fstps -24(%ebp)
movl
--- 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
--- 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.
--
--- 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. */
--- 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
--- 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 [0xffec])) [0
--- 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
--- 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=15074action=view)
patch for postreload-gcse
This fixes the oversight in postreload-gcse.c and this bug.
--
--- 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
--- 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
--- 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?
--
--- 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
--- 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
--- 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 [0xfff0])) [0 res$imag+0 S4 A]
on the edge from bb3 to
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|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
--- 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
--- 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
--- 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
--- 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
25 matches
Mail list logo
