Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[bangerth]

Old Synopsis: [3.2/3.3/3.4 regression] ICE with -Wunreachable-code
New Synopsis: [3.4 regression] ICE with -Wunreachable-code

State-Changed-From-To: closed->analyzed
State-Changed-By: bangerth
State-Changed-When: Mon Apr 28 17:59:58 2003
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.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10336

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[Jason Merrill]

The following reply was made to PR middle-end/10336; it has been noted by GNATS.

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.  */
 
 --=-=-=--

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[Giovanni Bajo]

The following reply was made to PR middle-end/10336; it has been noted by GNATS.

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
 

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[Wolfgang Bangerth]

The following reply was made to PR middle-end/10336; it has been noted by GNATS.

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/
 
 
 

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[Wolfgang Bangerth]

The following reply was made to PR middle-end/10336; it has been noted by GNATS.

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/
 
 

Re: middle-end/10336: [3.4 regression] ICE with -Wunreachable-code

[Steven Bosscher]

The following reply was made to PR middle-end/10336; it has been noted by GNATS.

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