First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 7507
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: hanwen@meddo.cs.uu.nl
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
PR7507.i.bz2 PR7507.i.bz2 application/octet-stream 2003-05-21 15:17 34.69 KB Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 7507 depends on: Show dependency tree
Show dependency graph
Bug 7507 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug

Description:   Last confirmed: Opened: 2002-08-06 07:06 
	(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 From Volker Reichelt 2002-11-27 08:13 ------- 
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 From Wolfgang Bangerth 2002-11-27 17:48 ------- 
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 From Volker Reichelt 2002-11-28 01:23 ------- 
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 From Christian Ehrhardt 2002-12-01 22:44 ------- 
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 From Christian Ehrhardt 2003-01-15 15:29 ------- 
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 From Christian Ehrhardt 2003-01-17 10:24 ------- 
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 From Richard Henderson 2003-01-21 09:16 ------- 
State-Changed-From-To: analyzed->closed
State-Changed-Why: Proposed patch accepted.
First Last Prev Next    No search results available      Search page      Enter new bug