Red Hat Bugzilla – Bug 88227
Internal compiler error in splice_child_die, at dwarf2out.c
Last modified: 2007-04-18 12:52:50 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Description of problem:
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):
Steps to Reproduce:
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.
Created attachment 90979 [details]
area.h - base class definition
Created attachment 90980 [details]
framework.h - derived class declaration
Created attachment 90981 [details]
event.h - a dependency framework.h has
Created attachment 90982 [details]
framework.cpp - class definition
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.
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...
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
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