Bug 88227 - Internal compiler error in splice_child_die, at dwarf2out.c
Internal compiler error in splice_child_die, at dwarf2out.c
Product: Red Hat Linux
Classification: Retired
Component: gcc3 (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2003-04-07 18:04 EDT by Dan Morrill
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-03 15:42:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
area.h - base class definition (551 bytes, text/plain)
2003-04-07 18:05 EDT, Dan Morrill
no flags Details
framework.h - derived class declaration (454 bytes, text/plain)
2003-04-07 18:06 EDT, Dan Morrill
no flags Details
event.h - a dependency framework.h has (632 bytes, text/plain)
2003-04-07 18:09 EDT, Dan Morrill
no flags Details
framework.cpp - class definition (777 bytes, text/plain)
2003-04-07 18:10 EDT, Dan Morrill
no flags Details

  None (edit)
Description Dan Morrill 2003-04-07 18:04:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

Description of problem:
gcc -v:
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

I will attach input files:  framework.c, framework.h, area.h, framework.cpp.  I
do not have a more reduced test case.

Error is this:
g++  -g -Wall  -c -o framework.o framework.cpp
framework.cpp:23: Internal compiler error in splice_child_die, at dwarf2out.c:
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.

See attached source files.  Should be fairly self-explanatory, but let me know
if it's not.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See code.

Additional info:

Mere formality, but... source code is not a trivial test case, but it's
BSD-licensed, so it's okay to throw around as needed.
Comment 1 Dan Morrill 2003-04-07 18:05:52 EDT
Created attachment 90979 [details]
area.h - base class definition
Comment 2 Dan Morrill 2003-04-07 18:06:34 EDT
Created attachment 90980 [details]
framework.h - derived class declaration
Comment 3 Dan Morrill 2003-04-07 18:09:40 EDT
Created attachment 90981 [details]
event.h - a dependency framework.h has
Comment 4 Dan Morrill 2003-04-07 18:10:13 EDT
Created attachment 90982 [details]
framework.cpp - class definition
Comment 5 Dan Morrill 2003-04-07 18:11:35 EDT
I have attached the problematic files -- I think this should compile but I am
not sure since gcc dies out. :)

If I can work around it I will add that info to this entry.
Comment 6 Dan Morrill 2003-04-07 18:18:07 EDT
Apparent workaround:  due to a copy-and-paste issue from area.h (the parent
class) there are a number of methods in framework.h that are defined to be
abstract but for which bodies exist in framework.cpp.  So, this is a
syntactically incorrect C++ file.

Obviously, that wasn't a graceful failure mode, though.

I will attempt to reproduce with a simpler test case...
Comment 7 Richard Henderson 2004-10-03 15:42:00 EDT
Actually, function bodies for abstract virtual functions is just fine.
You aren't allowed to invoke them implicitly (this->foo()), but you are
allowed to invoke them explicitly (this->base::foo()).

The real problem is that Framework::getName is implemented twice.  If
you remove the -g flag, the compiler won't crash, but you'll get 

/tmp/ccJPpA05.s: Assembler messages:
/tmp/ccJPpA05.s:505: Error: symbol `_ZN9Framework7getNameEv' is
already defined

Current versions of the compiler don't crash in the debug info, but
they don't diagnose the duplicate function definition either. Pushed
upstream to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17816

Note You need to log in before you can comment on or make changes to this bug.