Bug 7507 - [3.2/3.3 regression] ICE (segfault) with -O2
Summary: [3.2/3.3 regression] ICE (segfault) with -O2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.1.1
: P1 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 6875 9289 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-08-06 07:06 UTC by hanwen
Modified: 2003-07-25 17:33 UTC (History)
5 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
PR7507.i.bz2 (34.69 KB, application/octet-stream)
2003-05-21 15:17 UTC, hanwen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hanwen 2002-08-06 07:06:04 UTC
	(gdb) r -O2 gccsegv.c
eval.c: In function `scm_ceval':
eval.c:3314: internal error: Segmentatie fout
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Release:
3.1.1

Environment:
System: Linux meddo.cs.uu.nl 2.4.18 #1 di feb 26 12:12:46 CET 2002 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.1.1/configure --prefix=/users/hanwen/usr/pkg/gcc3 --program-suffix=3 --with-cpu=i686 --enable-languages=java,c++,c
Comment 1 Volker Reichelt 2002-11-27 08:13:59 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed.
    
    gcc 3.1 - 3.2.1 and mainline are affected.
    gcc 3.0.4 compiles the code without problems, however.
Comment 2 Wolfgang Bangerth 2002-11-27 17:48:13 UTC
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: optimization/7507: [3.2/3.3 regression] ICE (segfault) with -O2
Date: Wed, 27 Nov 2002 17:48:13 -0600 (CST)

 To be more specific about the SegFault Volker just found: it is here:
 
 Program received signal SIGSEGV, Segmentation fault.
 cached_make_edge (edge_cache=0x0, src=0x83e5d74, dst=0x0, flags=0)
     at ../../gcc-3.2-CVS/gcc/cfg.c:307
 (gdb) bt
 #0  cached_make_edge (edge_cache=0x0, src=0x83e5d74, dst=0x0, flags=0)
     at ../../gcc-3.2-CVS/gcc/cfg.c:307
 #1  0x08207655 in make_edges (label_value_list=0x0, min=0, max=3, update_p=1)
     at ../../gcc-3.2-CVS/gcc/cfgbuild.c:403
 #2  0x08207b9e in find_basic_blocks (f=0x401ae120, nregs=66, file=0x0)
     at ../../gcc-3.2-CVS/gcc/cfgbuild.c:663
 #3  0x081d9dab in rest_of_compilation (decl=0x401ada80)
     at ../../gcc-3.2-CVS/gcc/toplev.c:2639
 #4  0x08059bb3 in c_expand_body (fndecl=0x401ada80, nested_p=0, 
 can_defer_p=1)
     at ../../gcc-3.2-CVS/gcc/c-decl.c:7056
 #5  0x08059977 in finish_function (nested=0, can_defer_p=0)
     at ../../gcc-3.2-CVS/gcc/c-decl.c:6923
 #6  0x0804a04a in yyparse_1 () at c-parse.y:386
 #7  0x081d9424 in compile_file () at ../../gcc-3.2-CVS/gcc/toplev.c:2124
 #8  0x081de0b9 in do_compile () at ../../gcc-3.2-CVS/gcc/toplev.c:5218
 #9  0x081de129 in toplev_main (argc=0, argv=0x0)
     at ../../gcc-3.2-CVS/gcc/toplev.c:5250
 #10 0x08080e4b in main (argc=0, argv=0x0) at ../../gcc-3.2-CVS/gcc/main.c:35
 
 One would think that this is not target-specific, but it seems otherwise.
 
 The code in question is
 (gdb) fr 0
 #0  cached_make_edge (edge_cache=0x0, src=0x83e5d74, dst=0x0, flags=0)
     at ../../gcc-3.2-CVS/gcc/cfg.c:307
 
   else
     {
       e = (edge) obstack_alloc (&flow_obstack, sizeof *e);
       memset (e, 0, sizeof *e);
     }
   n_edges++;
 
   e->succ_next = src->succ;
   e->pred_next = dst->pred;          <<<<<<<<<<<<
   e->src = src;
   e->dest = dst;
   e->flags = flags;
 
   src->succ = e;
 
 
 because
 
 (gdb) p *e
 $1 = {pred_next = 0x0, succ_next = 0x0, src = 0x83e5d74, dest = 0x0, 
   insns = 0x0, aux = 0x0, flags = 0, probability = 0, count = 0}
 
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Comment 3 Volker Reichelt 2002-11-28 01:23:22 UTC
From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
        hanwen@meddo.cs.uu.nl
Cc:  
Subject: Re: optimization/7507: [3.2/3.3 regression] ICE (segfault) with -O2
Date: Thu, 28 Nov 2002 01:23:22 +0100

 Hi again,
 
 a distilled testcase is the following:
 
 ---------------------snip here---------------------
 void foo (int i);
 
 inline void bar () { return; }
 
 void baz (int (*p)(), void* q)
 {
   if (&p==q) foo( (bar(),p) () );
 }
 ---------------------snip here---------------------
 
 Compilation with gcc 3.1 - 3.2.1 on i686-pc-linu-gnu yields:
 
 PR7507.i: In function `baz':
 PR7507.i:8: internal error: Segmentation fault
 Please submit a full bug report, [etc.]
 
 The bug seems to be target specific, since I cannot reproduce it on
 mips-sgi-irix6.5.
 
 Regards,
 Volker
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7507
 
 

Comment 4 Christian Ehrhardt 2002-12-01 22:44:24 UTC
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
  nobody@gcc.gnu.org, hanwen@meddo.cs.uu.nl
Cc:  
Subject: Re: optimization/7507: [3.2/3.3 regression] ICE (segfault) with -O2
Date: Sun, 1 Dec 2002 22:44:24 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7507
 
 Hi,
 
 I tried to track this a bit more and came up with a slightly different
 example that still ices:
 ------------------- snip ---------------------
 extern int x (int);
 inline int bar (void) { return 1; }
 
 int foo (void)
 {
   x ((bar(), foo) ());
   return 2;
 }
 ------------------- snip ---------------------
 
 Which results in the following insns in .c.01.sibling (analyzed below):
 
 ------------------- cut ---------------------
 ;; Function foo
 
 
 
 try_optimize_cfg iteration 1
 
 Merged 0 and 1 without moving.
 
 
 try_optimize_cfg iteration 2
 
 (note 2 0 3 NOTE_INSN_DELETED)
 
 (note 3 2 57 NOTE_INSN_FUNCTION_BEG)
 
 (note 57 3 27 [bb 0] NOTE_INSN_BASIC_BLOCK)
 
 (note 27 57 28 3a6fc0 NOTE_INSN_BLOCK_BEG)
 
 (note 28 27 29 NOTE_INSN_DELETED)
 
 (note 29 28 31 NOTE_INSN_DELETED)
 
 (insn 31 29 32 (set (reg/v:SI 108)
         (const_int 1 [0x1])) -1 (nil)
     (nil))
 
 (jump_insn 32 31 33 (set (pc)
         (label_ref 19)) -1 (nil)
     (nil))
 
 (barrier 33 32 34)
 
 (note 34 33 35 3a6fc0 NOTE_INSN_BLOCK_END)
 
 (call_insn 35 34 37 (parallel[ 
             (set (reg:SI 8 %o0)
                 (call (mem:SI (symbol_ref:SI ("foo")) [0 S4 A32])
                     (const_int 0 [0x0])))
             (clobber (reg:SI 15 %o7))
         ] ) -1 (nil)
     (nil)
     (nil))
 
 (insn 37 35 39 (set (reg:SI 110)
         (reg:SI 8 %o0)) -1 (nil)
     (nil))
 
 (insn 39 37 40 (set (reg:SI 8 %o0)
         (reg:SI 110)) -1 (nil)
     (nil))
 
 (call_insn 40 39 46 (parallel[ 
             (set (reg:SI 8 %o0)
                 (call (mem:SI (symbol_ref:SI ("x")) [0 S4 A32])
                     (const_int 0 [0x0])))
             (clobber (reg:SI 15 %o7))
         ] ) -1 (nil)
     (nil)
     (expr_list (use (reg:SI 8 %o0))
         (nil)))
 
 (insn 46 40 49 (set (reg:SI 107)
         (const_int 2 [0x2])) -1 (nil)
     (nil))
 
 (note 49 46 53 NOTE_INSN_FUNCTION_END)
 
 (insn 53 49 56 (set (reg/i:SI 24 %i0)
         (reg:SI 107)) -1 (nil)
     (nil))
 
 (insn 56 53 0 (use (reg/i:SI 24 %i0)) -1 (nil)
     (nil))
 ------------------- cut ---------------------
 
 The jump insn should jump to a label after the inlined call to bar.
 The target label for this jump is never emitted. This is the reason
 for the segfault while finding basic blocks.
 The jump is added by replace_call_placeholder and it is only added if
 the sibcall_use_normal branch is taken.
 
     regards   Christian
 
 -- 
 THAT'S ALL FOLKS!
Comment 5 Christian Ehrhardt 2003-01-15 15:29:28 UTC
Responsible-Changed-From-To: unassigned->cae
Responsible-Changed-Why: I think I know what's going on. Expect a proposed patch to fix
    this by tomorrow.
Comment 6 Christian Ehrhardt 2003-01-17 10:24:34 UTC
Responsible-Changed-From-To: cae->unassigned
Responsible-Changed-Why: See the proposed patch in http://gcc.gnu.org/ml/gcc/2003-01/msg00835.html.
    That's all I can do for now.
Comment 7 Richard Henderson 2003-01-21 09:16:55 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: Proposed patch accepted.