[Bug c++/16240] New: Seg Fault in collect2

[Bug c++/16240] New: Seg Fault in collect2

[mckelvey at maskull dot com]

This code links if I add "inline" to the four Delete(...) functions in
StringScalarDeleteValue.h. Without that I get a seg fault.

/usr/local/bin/g++ -g -fno-elide-constructors       -pedantic-errors -Werror
-ansi -fno-common -fstrict-aliasing -Wall -W -Wold-style-cast -Wsign-promo
-Wpointer-arith -Wconversion -Wundef -Wwrite-strings -Winvalid-pch
-Woverloaded-virtual -Wcast-qual -Winline -Wextra -MMD     
-fimplicit-templates  -Wl,-warn-common -L.. -o test025.exe test025.o
-lPatternDriver -lintl
../libPatternDriver.a(StringScalarDeleteValue.o)(.text+0x1cc):/usr/home/mckelvey/PD/StringScalarDeleteValue.h:223:
multiple definition of `g++: Internal error: Segmentation fault (program
collect2)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake: *** [test025.exe] Error 1

alpha1:PD>g++ -v
Reading specs from /usr/local/lib/gcc/alphaev56-unknown-linux-gnu/3.5.0/specs
Configured with: ../gcc/configure --verbose --enable-languages=c++
Thread model: posix
gcc version 3.5.0 20040207 (experimental)

alpha1:PD>uname -a
Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown

alpha1:PD>alias CONFIGURECVS
alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++ >clog
2>&1'
alpha1:PD>alias BUILD
alias BUILD='nice gmake CFLAGS='\''-O'\'' BOOT_CFLAGS='\''-O'\''
LIBCFLAGS='\''-g -O'\'' LIBCXXFLAGS='\''-g -O -fno-implicit-templates'\''
bootstrap >log 2>&1'

I attach the .ii file; let me know if you need anything else.

-- 
           Summary: Seg Fault in collect2
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mckelvey at maskull dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alphaev56-unknown-linux-gnu
  GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu


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

[Bug c++/16240] Seg Fault in collect2

[mckelvey at maskull dot com]

------- Additional Comments From mckelvey at maskull dot com  2004-06-28 02:46 -------
Created an attachment (id=6640)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6640&action=view)
Compressed .ii file of source program causing problem.


-- 


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

[Bug driver/16240] Seg Fault in collect2

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |driver


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

[Bug driver/16240] Seg Fault in collect2

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-28 07:17 -------
I was able to reproduce it even without the libraries.

-- 


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

[Bug other/16240] [3.4/3.5 Regression] Seg Fault in collect2 (caused by C++ demangling)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-28 07:20 -------
Confirmed, it is trying to demangling this:
_ZN13PatternDriver23StringScalarDeleteValueC1ERKNS_25ConflateStringScalarValueERKNS_25AbstractS
tringScalarValueERKNS_12TemplateEnumINS_12pdcomplementELZNS_16complement_namesEELZNS_14
COMPLEMENTENUMEEEE

if you run it through c++filt from gcc 3.2.3 it works but not from HEAD binutil's c++filt (note that gcc 
no longer provides c++filt).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|driver                      |other
     Ever Confirmed|                            |1
  GCC build triplet|alphaev56-unknown-linux-gnu |
   GCC host triplet|alphaev56-unknown-linux-gnu |
 GCC target triplet|alphaev56-unknown-linux-gnu |
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-28 07:20:58
               date|                            |
            Summary|Seg Fault in collect2       |[3.4/3.5 Regression] Seg
                   |                            |Fault in collect2 (caused by
                   |                            |C++ demangling)
   Target Milestone|---                         |3.4.2


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

[Bug other/16240] [3.4/3.5 Regression] Seg Fault in collect2 (caused by C++ demangling)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-06-28 15:23 -------
Subject: Bug 16240

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	ian@gcc.gnu.org	2004-06-28 15:23:34

Modified files:
	libiberty      : ChangeLog cp-demangle.c 

Log message:
	PR other/16240
	* cp-demangle.c (d_expr_primary): Check for a failure return from
	cplus_demangle_type.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/ChangeLog.diff?cvsroot=gcc&r1=1.521&r2=1.522
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/cp-demangle.c.diff?cvsroot=gcc&r1=1.73&r2=1.74



-- 


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

[Bug other/16240] [3.4/3.5 Regression] Seg Fault in collect2 (caused by C++ demangling)

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-06-28 15:37 -------
I fixed the bug in the demangler which was causing it to dump core.  However,
that reveals a bug in the mangled name which g++ is generating.

Skipping the analysis of the whole name, here is the end:
    LZNS_16complement_namesEELZNS_14COMPLEMENTENUMEEEE
'L' means a template argument.
'Z' means a local name
'NS_16complement_namesE' is a nested name (PatternDriver::complement_names)
'E' starts the entity name of the local name

At this point we expect to see the name of a variable within the
PatternDriver::complement_names class.  Instead, we see another template
argument.  That is wrong.

The bug is in write_template_arg(), in the DECL_P case.  It has been there for a
long time.  I suspect that the correct patch is:

diff -p -u -r1.101 mangle.c
--- mangle.c	1 Apr 2004 03:50:39 -0000	1.101
+++ mangle.c	28 Jun 2004 15:36:01 -0000
@@ -2208,6 +2208,7 @@ write_template_arg (tree node)
       if (code == CONST_DECL)
 	G.need_abi_warning = 1;
       write_char ('L');
+      write_char ('_');
       write_char ('Z');
       write_encoding (node);
       write_char ('E');

Unfortunately, that would be an ABI change.

I don't see how to correctly demangle this symbol.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at wasabisystems dot com


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

[Bug c++/16240] [3.4/3.5 Regression] g++ generates incorrect mangled name

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-06-28 15:39 -------
Changed summary and component to reflect my analysis.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |c++
           Keywords|ice-on-valid-code           |
            Summary|[3.4/3.5 Regression] Seg    |[3.4/3.5 Regression] g++
                   |Fault in collect2 (caused by|generates incorrect mangled
                   |C++ demangling)             |name


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

[Bug c++/16240] [3.4/3.5 Regression] g++ generates incorrect mangled name

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-28 17:40 -------
Agreed. This is quoted by the C++ ABI:

          void foo(char); // mangled as _Z3fooc
          template<void (&)(char)> struct CB;
          // CB<foo> is mangled as "2CBIL_Z3foocEE"

Given this:

void foo(CB<foo>*);

we generate:

00000000 T _Z3fooP2CBILZ3foocEE

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
           Keywords|                            |ABI, wrong-code


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-07-01 17:23 -------

Added ABI to the subject

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.4/3.5 Regression] g++    |[3.4/3.5 ABI Regression] g++
                   |generates incorrect mangled |generates incorrect mangled
                   |name                        |name


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-02 23:56 -------
Subject: Bug 16240

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2004-07-02 23:56:38

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/cp         : ChangeLog mangle.c 
Added files:
	gcc/testsuite/g++.dg/abi: mangle22.C mangle23.C 

Log message:
	PR c++/16240
	* mangle.c (write_template_arg): Correct mangling.
	
	PR c++/16240
	* g++.dg/abi/mangle22.C: New test.
	* g++.dg/abi/mangle23.C: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3932&r2=1.3933
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/abi/mangle22.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/abi/mangle23.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4155&r2=1.4156
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/mangle.c.diff?cvsroot=gcc&r1=1.101&r2=1.102



-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-07-02 23:58 -------
Fixed in GCC 3.5.0 -- but only with -fabi-version=3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[jbuck at gcc dot gnu dot org]

------- Additional Comments From jbuck at gcc dot gnu dot org  2004-09-05 03:27 -------
I don't know why the target milestone was set to 3.4.2; there don't seem to be
any changes on the 3.4 branch reflecting this bug.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.5.0


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-31 22:12 -------
*** Bug 19730 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |unicorn at freeshell dot org


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-28 08:28 -------
Subject: Bug 16240

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-rhl-branch
Changes by:	jakub@gcc.gnu.org	2005-02-28 08:27:57

Modified files:
	libiberty      : ChangeLog cp-demangle.c 
	libiberty/testsuite: demangle-expected 

Log message:
	PR other/16240
	* cp-demangle.c (d_expr_primary): Check for a failure return from
	cplus_demangle_type.
	* testsuite/demangle-expected: Add test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.498.2.2.2.5&r2=1.498.2.2.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/cp-demangle.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.67.4.1.2.1&r2=1.67.4.1.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/testsuite/demangle-expected.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.27.4.1&r2=1.27.4.1.2.1



-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-07-27 22:48 -------
(In reply to comment #7)
> Agreed. This is quoted by the C++ ABI:
> 
>           void foo(char); // mangled as _Z3fooc
>           template<void (&)(char)> struct CB;
>           // CB<foo> is mangled as "2CBIL_Z3foocEE"
> 
> Given this:
> 
> void foo(CB<foo>*);
> 
> we generate:
> 
> 00000000 T _Z3fooP2CBILZ3foocEE


but c++filt _Z3fooP2CBILZ3foocEE, just returns the same string. But if I add '_'
as _Z3fooP2CBIL_Z3foocEE and then do c++filt on that string, returns
foo(CB<foo(char)>*) as expected.


-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2005-07-27 22:55 -------
In comment #7 Giovanni was saying that the compiler was generating the wrong
string.  The correct string is the one in the quote from the C++ ABI.  The
compiler has now been fixed the generate the correct string.

The demangler only handles the correct string.


-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-07-28 18:10 -------
(In reply to comment #15)
> In comment #7 Giovanni was saying that the compiler was generating the wrong
> string.  The correct string is the one in the quote from the C++ ABI.  The
> compiler has now been fixed the generate the correct string.
> 
> The demangler only handles the correct string.
> 

Does this means C++ ABI always (previous versions 1 and 2) had that '_'Z for the
template name mangling? If it is true, then how does adding '_' would cause an
ABI change, as you said in comment #5?  

-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2005-07-28 22:47 -------
I don't entirely understand your comment.

Older versions of g++ did not emit the underscore in this rather specific case.
 That was wrong.  Current versions of g++ do emit the underscore.  That is correct.

Adding the underscore was an ABI change because it means that you can not link
code compiled by old versions of g++ with code compiled with new versions of
g++, if the code happens to use this rather specific case.


-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-07-29 18:16 -------
I belive, till g++ 3.3.4, the mangled string used have that '_' as hown by
following example,

template<class T> struct S {
        S(int i=0);
};
template<S<int> &s> void f13();
extern S<int> s13;
int main(void)
{
        f13<s13>();
        return 0;
}

With nm, I get 
         U __gxx_personality_v0
00000000 T main
         U _Z3f13IXL_Z3s13EEEvv

Which I believe is the default and correct behavior. But with g++ > 3.4 (which
doesn't support abi-version=3) by default produces mangled string as
         U __gxx_personality_v0
00000000 T main
         U _Z3f13ILZ3s13EEvv

And with g++ > 3.5.x user has to specify -fabi-version=3  as specified by Mark,
to get the correct string.
So there is a binary compatibility problem between object code created by older
g++ version < 3.3.4 and later version till g++ version 3.5.

Do you see my dilemma? Or am I still missing something very basic here? 
Sorry for any/all repetition over this subject. I would really appreciate the
reply for better understanding and clarification of this issue.


-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2005-07-29 22:38 -------
I haven't checked g++ 3.3.x, but I have no reason to doubt you.  I think you
grasp the situation fine: at least for a while, g++ did not follow the ABI.  Now
it does.  It's a problem.  Any time you don't follow the ABI, it's a problem. 
It causes binary incompatibility, and forces people to recompile their code. 
People who don't have the source code are out of luck.

I'm not sure what question you are asking, if indeed you are asking a question
at all.  I'm not sure what else there is to say about the situation.


-- 


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2009-02-16 22:41 -------
*** Bug 39208 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dgregor at gcc dot gnu dot
                   |                            |org


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