Bug 10336

From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, reichelt@igpm.rwth-aachen.de,
	gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: c/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Mon, 07 Apr 2003 15:00:08 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10336
 
 Does this help?
 
 Index: jump.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/jump.c,v
 retrieving revision 1.221
 diff -c -3 -p -r1.221 jump.c
 *** jump.c    4 Apr 2003 01:21:56 -0000    1.221
 --- jump.c    7 Apr 2003 12:59:17 -0000
 *************** never_reached_warning (avoided_insn, fin
 *** 1912,1918 ****
     /* Back up to the first of any NOTEs preceding avoided_insn; flow passes
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
 !   for (insn = PREV_INSN (avoided_insn); ; insn = PREV_INSN (insn))
       if (GET_CODE (insn) != NOTE)
         {
       insn = NEXT_INSN (insn);
 --- 1912,1918 ----
     /* Back up to the first of any NOTEs preceding avoided_insn; flow passes
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
 !   for (insn = PREV_INSN (avoided_insn); insn; insn = PREV_INSN (insn))
       if (GET_CODE (insn) != NOTE)
         {
       insn = NEXT_INSN (insn);
 

From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: s.bosscher@student.tudelft.nl
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
 gcc-prs@gcc.gnu.org, jason@redhat.com
Subject: Re: c/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Mon, 07 Apr 2003 16:16:04 +0200 (CEST)

 On  7 Apr, Steven Bosscher wrote:
 > 
 > Does this help?
 
 Yes, this does indeed help (I just ran a full bootstrap and the ICE
 went away).
 
 Jason, you've applied the last patch to the code in jump.c,
 what do you think? Should the patch be applied to mainline?
 Should it also be applied to 3.2 and 3.3 branch, although
 the problem didn't show up on those branches?
 
 Regards,
 Volker
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10336
 
 

Responsible-Changed-From-To: unassigned->jason
Responsible-Changed-Why: You broke it.  Fix is probably obvious but may not be what you intended.

State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed and cause probably found.

From: Jason Merrill <jason@redhat.com>
To: steven@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
   reichelt@igpm.rwth-aachen.de, gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/10336: [3.3/3.4 regression] ICE with
 -Wunreachable-code
Date: Tue, 15 Apr 2003 04:28:24 +0100

 --=-=-=
 
 Thanks, I'm testing this patch now.  Yours leaves insn null for testcases
 that were crashing, so we wouldn't ever warn.
 
 
 --=-=-=
 Content-Type: text/x-patch
 Content-Disposition: inline
 
 *** jump.c.~2~	2003-04-03 18:54:32.000000000 -0500
 --- jump.c	2003-04-14 22:48:49.000000000 -0400
 *************** never_reached_warning (avoided_insn, fin
 *** 1913,1919 ****
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
     for (insn = PREV_INSN (avoided_insn); ; insn = PREV_INSN (insn))
 !     if (GET_CODE (insn) != NOTE)
         {
   	insn = NEXT_INSN (insn);
   	break;
 --- 1913,1920 ----
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
     for (insn = PREV_INSN (avoided_insn); ; insn = PREV_INSN (insn))
 !     if (GET_CODE (insn) != NOTE
 ! 	|| NOTE_LINE_NUMBER (insn) == NOTE_INSN_FUNCTION_BEG)
         {
   	insn = NEXT_INSN (insn);
   	break;
 
 --=-=-=--

From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: Jason Merrill <jason@redhat.com>
Cc: steven@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, reichelt@igpm.rwth-aachen.de,
	gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/10336: [3.3/3.4 regression] ICE with
	-Wunreachable-code
Date: 15 Apr 2003 08:32:52 +0200

 Op di 15-04-2003, om 05:28 schreef Jason Merrill:
 > Thanks, I'm testing this patch now.  Yours leaves insn null for testcases
 > that were crashing, so we wouldn't ever warn.
 > 
 
 Yea, I had a feeling you had someting else in mind.
 
 Thanks for the fix!
 
 Greetz
 Steven
 
 

State-Changed-From-To: analyzed->closed
State-Changed-Why: fixed

State-Changed-From-To: closed->analyzed
State-Changed-Why: See http://gcc.gnu.org/ml/gcc-bugs/2003-04/msg01274.html
    
    I can confirm that this small snippet
    ------------------------
    void foo(char a) { while (1); }
    ------------------------
    makes 3.4 segfault (both the C and C++ front end), as well
    as 3.3 (but only the C front end. It seems as if 3.2.3 is
    unaffected.
    
    W.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, Volker Reichelt <reichelt@igpm.rwth-aachen.de>,
   <gcc-bugs@gcc.gnu.org>, <jason@gcc.gnu.org>
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Mon, 28 Apr 2003 19:09:33 -0500 (CDT)

 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10336
 
 > I fixed a bug some time ago where such a loop ignored
 > BARRIER insns, walked the whole list of INSNs until insn
 > was NULL, which caused a segfault.  It seems that for
 > this test case, the same thing happens in your new loop.
 > 
 > You can see in gdb that the C front end is ignoring
 > "(barrier 14 13 15)".  Two insns later you have a the
 > segfault...
 > 
 > So maybe something like this would fix it??
 > 
 > + for (insn = PREV_INSN (avoided_insn);
 > +      GET_CODE (insn) != BARRIER;
 > +      insn = PREV_INSN (insn))
 > 
 > Assuming PREV_INSN (avoided_insn) is never NULL, but of
 > course we make that assumption now, too.
 > 
 > Can't test it this week.  Wolfgang, maybe you can, and if
 > it works, submit a patch and use your new privileges? :-)
 
 Too bad ;-) I tried it, but it ain't workin', assuming I did it right.  
 Since this about exhausts my possibilities (not knowing all this stuff), I
 fear I have to leave this to more experienced hackers. At least the 
 testcase is short...
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, reichelt@igpm.rwth-aachen.de,
	gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org,
	bangerth@gcc.gnu.org
Cc:  
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Tue, 29 Apr 2003 00:29:12 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10336
 
 Jason,
 
 Your patch added this line:
 
 + for (insn = PREV_INSN (avoided_insn); ; insn = PREV_INSN (insn))
 
 I fixed a bug some time ago where such a loop ignored
 BARRIER insns, walked the whole list of INSNs until insn
 was NULL, which caused a segfault.  It seems that for
 this test case, the same thing happens in your new loop.
 
 You can see in gdb that the C front end is ignoring
 "(barrier 14 13 15)".  Two insns later you have a the
 segfault...
 
 So maybe something like this would fix it??
 
 + for (insn = PREV_INSN (avoided_insn);
 +      GET_CODE (insn) != BARRIER;
 +      insn = PREV_INSN (insn))
 
 Assuming PREV_INSN (avoided_insn) is never NULL, but of
 course we make that assumption now, too.
 
 Can't test it this week.  Wolfgang, maybe you can, and if
 it works, submit a patch and use your new privileges? :-)
 
 Greetz
 Steven
 
 
 

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
 (fwd)
Date: Tue, 29 Apr 2003 12:19:26 -0500 (CDT)

 ---------- Forwarded message ----------
 Date: Tue, 29 Apr 2003 19:04:27 +0200
 From: Giovanni Bajo <giovannibajo@libero.it>
 To: Wolfgang Bangerth <bangerth@ices.utexas.edu>, s.bosscher@student.tudelft.nl
 Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
 
 Hello,
 
 I tried both testcases available in PR/10336 (the original one and the new
 one), but I cannot reproduce the bug with either of this:
 
 $ gcc-3.3 -v
 Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/3.3/specs
 Configured with:
 ../gcc/configure --program-suffix=-3.3 --enable-languages=c,c++
  --enable-threads=posix --enable-shared --enable-checking
 Thread model: posix
 gcc version 3.3 20030421 (prerelease)
 
 $ gcc-3.4 -v
 Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/3.4/specs
 Configured with:
 ../gcc/configure --enable-languages=c,c++ --program-suffix=-3.4
  --enable-threads=posix --enable-shared
 Thread model: posix
 gcc version 3.4 20030428 (experimental)
 
 
 I tried both the C and the C++ frontend. Command line was simply
 "gcc -c -Wunreachable-code".
 
 Moreover, the audit trail says that the bug is still present in the C
 frontend for 3.3: in this case, it should be marked as a 3.3 regression as
 well (and probably showstopper for the release, given that it breaks the
 feature with very easy code snippets).
 
 Giovanni Bajo
 

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: s.bosscher@student.tudelft.nl, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Tue, 29 Apr 2003 12:20:19 -0500 (CDT)

 > I tried both the C and the C++ frontend. Command line was simply
 > "gcc -c -Wunreachable-code".
 
 -Wunreablable-code only works with -O. Could you please double check your 
 results with this?
 
 Thanks
   W.
 
 PS: Don't forget to keep gcc-gnats@... as a CC:
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
 

From: Jason Merrill <jason@redhat.com>
To: bangerth@dealii.org
Cc: gcc-bugs@gcc.gnu.org, reichelt@igpm.rwth-aachen.de, gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Tue, 29 Apr 2003 13:32:15 -0400

 --=-=-=
 
 Well, this has been an annoyingly persistent problem.  :) 
 I'm testing this patch now:
 
 
 --=-=-=
 Content-Type: text/x-patch
 Content-Disposition: inline
 
 *** jump.c.~1~	2003-04-29 12:32:39.000000000 -0400
 --- jump.c	2003-04-29 12:57:54.000000000 -0400
 *************** never_reached_warning (avoided_insn, fin
 *** 1912,1924 ****
     /* Back up to the first of any NOTEs preceding avoided_insn; flow passes
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
 !   for (insn = PREV_INSN (avoided_insn); ; insn = PREV_INSN (insn))
 !     if (GET_CODE (insn) != NOTE
 ! 	|| NOTE_LINE_NUMBER (insn) == NOTE_INSN_FUNCTION_BEG)
 !       {
 ! 	insn = NEXT_INSN (insn);
   	break;
 !       }
   
     /* Scan forwards, looking at LINE_NUMBER notes, until we hit a LABEL
        in case FINISH is NULL, otherwise until we run out of insns.  */
 --- 1912,1926 ----
     /* Back up to the first of any NOTEs preceding avoided_insn; flow passes
        us the head of a block, a NOTE_INSN_BASIC_BLOCK, which often follows
        the line note.  */
 !   insn = avoided_insn;
 !   while (1)
 !     {
 !       rtx prev = PREV_INSN (insn);
 !       if (prev == NULL_RTX
 ! 	  || GET_CODE (prev) != NOTE)
   	break;
 !       insn = prev;
 !     }
   
     /* Scan forwards, looking at LINE_NUMBER notes, until we hit a LABEL
        in case FINISH is NULL, otherwise until we run out of insns.  */
 
 --=-=-=--

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: s.bosscher@student.tudelft.nl, <gcc-gnats@gcc.gnu.org>,
   Jason Merrill <jason@redhat.com>, <mark@codesourcery.com>
Subject: Re: middle-end/10336: [3.3/3.4 regression] ICE with -Wunreachable-code
Date: Tue, 29 Apr 2003 13:44:09 -0500 (CDT)

 > Ah, sorry. Confirmed with 3.3/3.4 (C frontend) and 3.4 only (C++ frontend).
 > I think the synopsis should be changed to report the 3.3 regression.
 
 OK, I did that.
 
 Mark, can you add this to your watch-list? My gut tells me that we will 
 get _lots_ of PRs from this one otherwise. Jason's got a tentative patch, 
 so we might have a resolution there soon.
 
 Jason, can you make sure this goes into 3.3 as well if the patch works 
 and Mark agrees?
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
 

From: "Giovanni Bajo" <giovannibajo@libero.it>
To: "Wolfgang Bangerth" <bangerth@ices.utexas.edu>
Cc: <s.bosscher@student.tudelft.nl>,
	<gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code
Date: Tue, 29 Apr 2003 19:27:26 +0200

 Wolfgang Bangerth <bangerth@ices.utexas.edu> wrote:
 
 > -Wunreablable-code only works with -O. Could you please double check your
 > results with this?
 
 Ah, sorry. Confirmed with 3.3/3.4 (C frontend) and 3.4 only (C++ frontend).
 I think the synopsis should be changed to report the 3.3 regression.
 
 gcc version 3.3 20030421 (prerelease)
 gcc version 3.4 20030428 (experimental)
 
 > PS: Don't forget to keep gcc-gnats@... as a CC:
 
 
 That was intentional. I was trying not to pollute the audit trail in case it
 was a mistake on my side, as it turned out to be.
 
 Giovanni Bajo
 

State-Changed-From-To: analyzed->closed
State-Changed-Why: fixed