Bug 17186 - [3.4 regression] ICE in move_for_stack_reg, at reg-stack.c:1065
Summary: [3.4 regression] ICE in move_for_stack_reg, at reg-stack.c:1065
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.1
: P2 critical
Target Milestone: 3.4.4
Assignee: Richard Henderson
URL:
Keywords: ice-on-valid-code, monitored
: 17485 17486 17487 19572 (view as bug list)
Depends on:
Blocks: 17414
  Show dependency treegraph
 
Reported: 2004-08-25 14:18 UTC by Herton Ronaldo Krzesinski
Modified: 2005-01-23 17:49 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.3.4 4.0.0
Known to fail: 3.4.1
Last reconfirmed: 2004-09-12 16:22:59


Attachments
preprocessed source (26.56 KB, application/octet-stream)
2004-08-25 14:21 UTC, Herton Ronaldo Krzesinski
Details
testcase for regression introduced by patch (71.38 KB, text/plain)
2004-09-11 22:13 UTC, Richard Earnshaw
Details
sjlj proposed patch (491 bytes, patch)
2004-09-12 00:23 UTC, Richard Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Herton Ronaldo Krzesinski 2004-08-25 14:18:52 UTC
gcc -O3  -I../include -I.    -c -o math.o math.c 
math.c: In function `ma_lnfactorial': 
math.c:1691: internal compiler error: in move_for_stack_reg, at 
reg-stack.c:1065 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
make: ** [math.o] Erro 1 
 
gcc -v 
====== 
Reading specs from /usr/lib/gcc/i386-conectiva-linux/3.4.1/specs 
Configured with: ../configure --prefix=/usr --bindir=/usr/bin 
--libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info 
--datadir=/usr/share --enable-shared --disable-checking --enable-long-long 
--enable-__cxa_atexit --enable-threads=posix --disable-libunwind-exceptions 
--enable-libgcj --enable-languages=c,c++,f77,objc,java --with-system-zlib 
--host=i386-conectiva-linux --target=i386-conectiva-linux 
--with-gxx_include_dir=/usr/include/c++/3.4.1 
Thread model: posix 
gcc version 3.4.1
Comment 1 Herton Ronaldo Krzesinski 2004-08-25 14:21:44 UTC
Created attachment 6988 [details]
preprocessed source

here goes the file to reproduce the problem:

1) bunzip2 math.i.bz2
2) gcc -O3 -c -o math.o math.i
Comment 2 Herton Ronaldo Krzesinski 2004-08-25 14:24:53 UTC
I don't know if this problem is similar to problems described in bugs #15832 
and #16009, it looks like a different issue and occurs with gcc 3.4.1 that I'm 
using. 
Comment 3 Volker Reichelt 2004-08-25 14:58:02 UTC
Here's a reduced testcase - just compile with gcc -O2:

===============================
double foo()
{
    int i;
    double d;

    if (i)
        bar();
    else
        if (d) return 0;
}
===============================
Comment 4 Andrew Pinski 2004-08-25 15:02:25 UTC
: Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446).
: Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2).

Hmm, this looks unrelated to those two bugs but it might be easy to find as it was put in both the 
mainline and the 3.4 branch.
Comment 5 Volker Reichelt 2004-08-25 15:37:55 UTC
Richard, Ian, this was introduced by your patch for PR 1532:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00585.html

Could you please have a look?
Comment 6 Mark Mitchell 2004-08-29 18:11:55 UTC
Postponed until GCC 3.4.3.
Comment 7 Mark Mitchell 2004-08-29 18:14:42 UTC
Postponed until GCC 3.4.3.
Comment 8 Ian Lance Taylor 2004-09-02 03:16:19 UTC
I took a quick look.  I think the basic problem is that the register stack pass
expects the register liveness information to match the instructions used.  The
test case is a tricky one because the function often does not return any value.  

Before the basic block reordering pass, the function looks approximately like this:

st = 0;
st(1) = st;
if (eax != 0)
  bar();
st = st(1);

After the basic block reordering pass, the function is rewritten to look
approximately like this:

st = 0;
st(1) = st;
if (eax == 0)
  st = st(1);
else {
  bar();
  st = st(1);
}

Since the function returns the type double, the return value can be found in st.
 Note that st and st(1) are clobbered by the function call to bar().  This
doesn't matter when compiling this function, because in the case where bar() is
called, no return value is specified.  However, this means that in the last
basic block, st(1) is not live on entry.  Since reg-stack does not expect to see
a reference to a register which is not live on entry to the block and is not set
 inside the block, it blows up.

At this point I do not know what the right fix is.  If the final copy of "st =
st(1);" were removed, the compiler would probably not blow up.  That instruction
was created by the basic block reordering pass, when it inserted a new basic
block.  However, it is useless, since it just copies around a dead value. 
Alternatively, perhaps reg-stack should not be so fussy.

I don't think this bug has much to do with the patch which Richard wrote and I
checked in.  That patch presumably hides this bug in some manner.  But I would
expect that there is still a latent bug which could surface whenever the block
reordering pass duplicates an assignment of values which are actually dead.
Comment 9 Richard Henderson 2004-09-03 20:46:50 UTC

*** This bug has been marked as a duplicate of 15832 ***
Comment 10 Volker Reichelt 2004-09-07 08:55:39 UTC
The testcase in comment #3 still fails for me on mainline and 3.4 branch.
Comment 11 Richard Henderson 2004-09-07 19:02:12 UTC
Ah, I see.  The test case passes for -mtune=i386, but not -mtune=i686,
and I had forgotten that cc1 no longer chooses the configury default.
Comment 12 Richard Henderson 2004-09-07 19:51:21 UTC
Testing a patch.
Comment 13 GCC Commits 2004-09-08 19:25:11 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-09-08 19:25:04

Modified files:
	gcc            : ChangeLog function.c 
Added files:
	gcc/testsuite/gcc.c-torture/compile: 20040908-1.c 

Log message:
	PR rtl-opt/17186
	* function.c (expand_function_end): Have fall-off-the-end
	return path jump around return register setup.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5309&r2=2.5310
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.573&r2=1.574
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20040908-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 14 GCC Commits 2004-09-08 19:35:49 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	rth@gcc.gnu.org	2004-09-08 19:35:42

Modified files:
	gcc            : ChangeLog function.c 

Log message:
	PR rtl-opt/17186
	* function.c (expand_function_end): Have fall-off-the-end
	return path jump around return register setup.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.613&r2=2.2326.2.614
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.483.4.16&r2=1.483.4.17

Comment 15 Richard Henderson 2004-09-08 19:36:22 UTC
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00749.html
Comment 16 Richard Earnshaw 2004-09-11 11:19:45 UTC
This patch causes regressions on arm-unknown-elf.

Specifically, g++.old-deja/g++.brendan/crash15.C now fails to compile with an ICE.
Comment 17 Richard Henderson 2004-09-11 21:19:56 UTC
Gimme .i file.
Comment 18 Richard Earnshaw 2004-09-11 22:13:45 UTC
Created attachment 7101 [details]
testcase for regression introduced by patch
Comment 19 Richard Earnshaw 2004-09-11 22:14:41 UTC
Attachment provided
Comment 20 Richard Henderson 2004-09-12 00:23:24 UTC
Created attachment 7102 [details]
sjlj proposed patch

Looks like latent bug in the SJLJ code.  Try this.
Comment 21 Andrew Pinski 2004-09-12 00:26:27 UTC
I almost want to say that patch also fixes PR 17414, I am trying that patch right now on openbsd.
Comment 22 Steven Bosscher 2004-09-12 00:28:57 UTC
Given the patch I just posted to Pinski, this is almost certainly a dup of 
PR17414 
Comment 23 Andrew Pinski 2004-09-12 00:36:26 UTC
I tested the patch on the testcase in PR 17414 with a cross compiler to hppa64-hp-hpux11.11 and it 
fixes that ICE.
Comment 24 Richard Earnshaw 2004-09-12 16:22:58 UTC
Yep, that fixes the ICEs.
Comment 25 GCC Commits 2004-09-12 17:22:08 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-09-12 17:22:04

Modified files:
	gcc            : ChangeLog except.c 

Log message:
	PR 17186, part deux
	* except.c (sjlj_emit_function_exit): Fix logic locating
	sjlj_exit_after in final block.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5405&r2=2.5406
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/except.c.diff?cvsroot=gcc&r1=1.286&r2=1.287

Comment 26 Richard Henderson 2004-09-12 17:35:36 UTC
Fixed.
Comment 27 Richard Earnshaw 2004-09-13 09:42:50 UTC
(In reply to comment #26)
> Fixed.

You applied the first patch to the 3.4 branch as well.  Doesn't the second patch
need backporting too?

R.
Comment 28 Richard Henderson 2004-09-13 19:03:07 UTC
Subject: Re:  [3.4/3.5 regression] ICE in move_for_stack_reg, at reg-stack.c:1065

On Mon, Sep 13, 2004 at 09:42:54AM -0000, rearnsha at gcc dot gnu dot org wrote:
> You applied the first patch to the 3.4 branch as well.
> Doesn't the second patch need backporting too?

I don't know, does it?  In any case someone will want to be
testing the backport on a system that uses it.  Will you?


r~
Comment 29 Richard Henderson 2004-09-14 21:38:47 UTC
The answer is no, the sjlj patch does not need backporting to 3.4;
the code being patched is new for 4.0, due to expanding the tree 
cfg directly into the rtl cfg.

But reopening to track sibcall and warning regressions in 3.4, for
which I am testing a patch.
Comment 30 Andrew Pinski 2004-09-14 21:43:49 UTC
*** Bug 17487 has been marked as a duplicate of this bug. ***
Comment 31 Andrew Pinski 2004-09-14 21:43:53 UTC
*** Bug 17486 has been marked as a duplicate of this bug. ***
Comment 32 Andrew Pinski 2004-09-14 21:43:58 UTC
*** Bug 17485 has been marked as a duplicate of this bug. ***
Comment 33 GCC Commits 2004-09-15 05:37:57 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	rth@gcc.gnu.org	2004-09-15 05:37:47

Modified files:
	gcc            : ChangeLog function.c 

Log message:
	PR rtl-opt/17186
	* function.c (expand_function_end): Revert last change.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.623&r2=2.2326.2.624
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.483.4.17&r2=1.483.4.18

Comment 34 Richard Henderson 2004-09-15 05:49:13 UTC
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01515.html
Comment 35 Mark Mitchell 2004-11-01 00:46:16 UTC
Postponed until GCC 3.4.4.
Comment 36 GCC Commits 2004-12-13 02:32:15 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-12-13 02:32:08

Modified files:
	gcc            : ChangeLog reg-stack.c 

Log message:
	PR rtl-opt/17186
	* reg-stack.c (move_nan_for_stack_reg): New.
	(subst_stack_regs_pat): Use it.
	(move_for_stack_reg): Handle source register not live with a nan.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6797&r2=2.6798
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reg-stack.c.diff?cvsroot=gcc&r1=1.170&r2=1.171

Comment 37 GCC Commits 2004-12-13 02:34:22 UTC
Subject: Bug 17186

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	rth@gcc.gnu.org	2004-12-13 02:34:16

Modified files:
	gcc            : ChangeLog reg-stack.c 

Log message:
	PR rtl-opt/17186
	* reg-stack.c (move_for_stack_reg): Handle source register not
	live with a nan.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.728&r2=2.2326.2.729
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reg-stack.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.140.4.1&r2=1.140.4.2

Comment 38 Richard Henderson 2004-12-13 02:37:08 UTC
Fixed.
Comment 39 Volker Reichelt 2005-01-23 17:49:00 UTC
*** Bug 19572 has been marked as a duplicate of this bug. ***