Bug 145781 - c++filt seg faults on symbol produced by g++ 3.4.3
c++filt seg faults on symbol produced by g++ 3.4.3
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc3 (Show other bugs)
3.0
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-21 11:00 EST by Andrew Godbout
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-257
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 09:42:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 16240 None None None Never

  None (edit)
Description Andrew Godbout 2005-01-21 11:00:56 EST
Description of problem:
This appears to either be a c++filt or g++ (or both problem), in 
either case c++filt 
should not core on the g++ name, although it appears to me as though 
the mangled name produced
by g++ is also incorrect.

I have included the testsource I am using and the steps to reproduce 
further down. 

Essentially we are trying to generate a symbol for 

f13<s13>();

where f13 is defined as: template void f13<s13>();

and s13 is an external name from an included header file: extern 
S<int> s13;

Previous versions of g++ (gcc version 3.2.3 20030502 (Red Hat Linux 
3.2.3-42)) produce the following mangled name for void f13<s13>():
_Z3f13IXL_Z3s13EEEvv

however with g++ in RHEL 4 RC 1 (gcc-c++-3.4.3-6.EL4) the mangled 
name produced is: _Z3f13ILZ3s13EEvv

attempting to demangle the name with C++filt we get:
$ c++filt _Z3f13ILZ3s13EEvv
Segmentation fault

I have looked at the itanium c++ ABI and it appears as though g++ has 
changed their behaviour for this symbol, it appears as though now 
they follow a different path in generating the symbol.

Previously (RHEL 3) it looks like they mangled the template argument 
portion of the name as
<template-args> ::= I <template-arg>+ E
where the template-arg breaks down as <template-arg> ::= X 
<expression> E <- so s13 would be the expression and now it appears 
as though g++ is mangling the template-arg as:
<template-arg> ::= <expr-primary>

However <expr-primary> is supposed to break down into <expr-
primary> ::= L <mangled-name> E <- so s13 would be the mangled name.
and a mangled name starts with _Z which would place an _Z in the 
middle of the symbol, which we don't have.

So assuming the new mangling of the <template-arg> is expected I 
think the symbol g++ indends to generate is 
actually:
_Z3f13IL_Z3s13EEvv as opposed to _Z3f13ILZ3s13EEvv
        ^
(notice the _Z) in the middle of the symbol.

Can you please confirm 2 things 
1: g++ has changed the way it generates the template-args for 
   this case (now uses the new path described above)
2: The missing '_' in the middle is in fact an error.

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

64 bit powerpc with kernel: 2.6.9-1.849_EL
g++ and gcc from:
gcc-c++-3.4.3-6.EL4 (gcc version 3.4.3 20041125 (Red Hat 3.4.3-
6.EL4) )

How reproducible:

Here are the source files I am using

// Start t2.h //
extern S<int> s13;
// end t2.h //

// start t3.h // 
template<class T> struct S {
        S(int i=0);
};

template<S<int> &s> void f13();
// end t3.h //

// start t1.C //
#include "t3.h"
#include "t2.h"
int main(void)
{
        f13<s13>();
        return 0;
}
// end t1.C //

// start t.C //
#include "t3.h"
#include "t2.h"

template< S<int> &s> void f13() { (void) s; }
template void f13<s13>();

// end t.C //

Steps to Reproduce:
1.g++ t1.C   <= This will crash with internal error 

or
2.g++ -c t1.C 
3.nm t1.o
4.c++filt _Z3f13ILZ3s13EEvv
  
Actual results:
$ g++ t1.C
/tmp/ccqIcaJx.o(.text+0x14): In function `main':
: undefined reference to `g++: Internal error: Segmentation fault 
(program collect2)
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.


Expected results:
$ g++ t1.C
/tmp/cc6if8yf.o(.text+0x14): In function `main':
: undefined reference to `void f13<s13>()'
collect2: ld returned 1 exit status


Additional info:
Comment 1 Jakub Jelinek 2005-01-28 08:34:34 EST
The libiberty/* part of PR c++/16240 has been checked into our package CVS
and will be added for RHEL3 U5 and RHEL4 U1 gcc.
The mangle.c fix not, g++ 3.4 doesn't support -fabi-version=3 and even
g++ 4.0 is likely going to use -fabi-version=2 by default.
Comment 2 Jakub Jelinek 2005-01-29 03:13:16 EST
For RHEL3, this ought to be fixed in gcc-3.2.3-51.
I've uploaded it to ftp://people.redhat.com/jakub/gcc/3.2.3-51/
for the time being.
Comment 3 Jakub Jelinek 2005-03-01 07:25:54 EST
And for RHEL4 this is fixed in gcc-3.4.3-21.
Comment 4 Tim Powers 2005-05-18 09:42:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-258.html
Comment 8 Vincent S 2006-06-16 00:43:00 EDT
Hello All,

In my machine gcc 3.2.3 crashes sporadically in Red Hat Enterprise Linux 3
Update 6 Virtual Machine.

gcc sometimes crashes with this error message:

/usr/include/c++/3.2.3/bits/stl_vector.h:108: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.

Could this too be related to this bug and will upgrading to the 3.4.3-21 help

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