[Bug c++/23651] New: ICE in GC

[snyder at fnal dot gov]

Release:   gcc (GCC) 4.1.0 20050831 (experimental)
Environment:
System: Linux karma 2.6.12.1sss #2 Thu Jul 7 00:28:21 EDT 2005 i686 i686 i386
GNU/Linux
Architecture: i686

machine, os, target, libraries (multiple lines)
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc
--enable-threads=posix --enable-long-long --enable-languages=c,c++,f95

On the attached source, g++ dies with an ICE in garbage collection
when it is compiled as follows:

$ g++ -c -O3 -fPIC -g  y.cc
y.cc: In function 'int foo()':
y.cc:14681: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
$

Here's where it's crashing:

Program received signal SIGSEGV, Segmentation fault.
0x08505e77 in gt_ggc_mx_basic_block_def (x_p=0xb7384960) at gtype-desc.c:445
445   gt_ggc_m_9tree_node ((*x).stmt_list);
#0  0x08505e77 in gt_ggc_mx_basic_block_def (x_p=0xb7384960)
at gtype-desc.c:445
#1  0x08508634 in gt_ggc_mx_rtx_def (x_p=0xb7350258) at gtype-desc.c:1369
#2  0x08508434 in gt_ggc_mx_rtx_def (x_p=0xb722ee7c) at gtype-desc.c:1341
#3  0x085064b8 in gt_ggc_mx_function (x_p=0xb74a9400) at gtype-desc.c:624
#4  0x081d8774 in gt_ggc_mx_lang_tree_node (x_p=0xb7564a50)
at ./gt-cp-tree.h:320
#5  0x0820d235 in gt_ggc_mx_cp_binding_level (x_p=0xb7e01190)
at ./gt-cp-name-lookup.h:65
#6  0x0820d3f4 in gt_ggc_mx_cxx_binding (x_p=0xb7df87c8)
at ./gt-cp-name-lookup.h:91
#7  0x081d940e in gt_ggc_mx_lang_tree_node (x_p=0xb7e09ed4)
at ./gt-cp-tree.h:521
#8  0x081d8451 in gt_ggc_mx_lang_tree_node (x_p=0xb7e11270)
at ./gt-cp-tree.h:285
#9  0x081d88c4 in gt_ggc_mx_lang_tree_node (x_p=0xb7e0a2e0)
at ./gt-cp-tree.h:344
#10 0x081d8a22 in gt_ggc_mx_lang_tree_node (x_p=0xb7e0b000)
at ./gt-cp-tree.h:362
#11 0x081d87d7 in gt_ggc_mx_lang_tree_node (x_p=0xb7e0a000)
at ./gt-cp-tree.h:326
#12 0x081d744a in gt_ggc_mx_lang_tree_node (x_p=0xb7df8540)
at ./gt-cp-tree.h:85
...

Apologies for the large size of the test case, but i've already spent
a huge amount of time reducing it.  Almost any perturbation in either
the test case or the compiler is likely to make the crash go away.

To further pinpoint the version of the compiler i'm using,
here are the most recent entries in gcc/ChangeLog and gcc/cp/ChangeLog
that i have checked out:

2005-08-30  Richard Henderson  [EMAIL PROTECTED]

PR target/23630
* expr.c (expand_expr_real_1) VIEW_CONVERT_EXPR: Use gen_lowpart
whenever the mode sizes match.


2005-08-30  Volker Reichelt  [EMAIL PROTECTED]

PR c++/23586
* parser.c (cp_parser_namespace_name): Move diagnostic for
invalid namespace-name to here from ...
* name-lookup.c (do_namespace_alias): ... here and ...
(do_using_directive): ... here.  Remove dead code.

-- 
   Summary: ICE in GC
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snyder at fnal dot gov
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23651

[Bug c++/23651] ICE in GC

[snyder at fnal dot gov]

--- Additional Comments From snyder at fnal dot gov  2005-08-31 09:44 
---
Created an attachment (id=9630)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9630action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23651

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

[snyder at fnal dot gov]

--- Additional Comments From snyder at fnal dot gov  2005-02-08 20:18 
---
(In reply to comment #24)
 (In reply to comment #23)
  This does not seem to be fixed so reopening.
 I opened another PR because it is related but not fully the same problem.  (PR
19699).

We still (as of CVS from Feb 8) get the warning if the throw-specifier is
not empty.

This example still gives the warning with -Wall -O1:

struct E{};

inline int bar() throw(E)
{
  return 0;
}

void foo ()
{
  bar();
}

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583