* [Bug debug/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
2010-11-20 16:06 [Bug debug/46580] New: -fcompare-debug failure with -gstabs -g due to different symbol mangling zsojka at seznam dot cz
@ 2010-11-20 16:13 ` zsojka at seznam dot cz
2010-11-20 16:45 ` zsojka at seznam dot cz
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: zsojka at seznam dot cz @ 2010-11-20 16:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580
--- Comment #1 from Zdenek Sojka <zsojka at seznam dot cz> 2010-11-20 16:05:51 UTC ---
Created attachment 22470
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22470
another testcase
$ gcc -gstabs -g -fcompare-debug testcase2.C
gcc: error: testcase2.C: -fcompare-debug failure (length)
$ diff testcase2.*gkd
3c3
< ;; Function (_ZN1f1fEv)
---
> ;; Function (_ZN3._01fEv)
First one demangles into "f::f()", second into "._0::f()"
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug debug/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
2010-11-20 16:06 [Bug debug/46580] New: -fcompare-debug failure with -gstabs -g due to different symbol mangling zsojka at seznam dot cz
2010-11-20 16:13 ` [Bug debug/46580] " zsojka at seznam dot cz
@ 2010-11-20 16:45 ` zsojka at seznam dot cz
2010-11-21 9:35 ` [Bug c++/46580] " aoliva at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: zsojka at seznam dot cz @ 2010-11-20 16:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580
Zdenek Sojka <zsojka at seznam dot cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
Known to fail| |4.2.4, 4.3.5, 4.4.6
--- Comment #2 from Zdenek Sojka <zsojka at seznam dot cz> 2010-11-20 16:29:57 UTC ---
For the second testcase, all 4.2.4, 4.3.5, 4.4.6, 4.5.2 and 4.6.0 generate
different symbol names for "-gstabs -g" case, compared to "" case.
gcc 4.0.4 and 4.1.2 don't generate any code at all (?)
gcc 3.3.6 and 3.4.6 generate same symbol names, _ZN1f1fEv. I don't know if
that's by luck or not, so I am not adding them to the "Known to work" field.
The function can be renamed to something else than "f()", the problem persists.
First testcase seems to fail only in 4.5 and 4.6.
This probably isn't typical -fcompare-debug failure.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug c++/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
2010-11-20 16:06 [Bug debug/46580] New: -fcompare-debug failure with -gstabs -g due to different symbol mangling zsojka at seznam dot cz
2010-11-20 16:13 ` [Bug debug/46580] " zsojka at seznam dot cz
2010-11-20 16:45 ` zsojka at seznam dot cz
@ 2010-11-21 9:35 ` aoliva at gcc dot gnu.org
2021-09-20 6:06 ` pinskia at gcc dot gnu.org
2021-09-20 6:19 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-11-21 9:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.11.21 09:23:01
Component|debug |c++
Ever Confirmed|0 |1
--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-11-21 09:23:01 UTC ---
Indeed, not a typical -fcompare-debug error.
I looked a bit into the second testcase. The problem is that finish_struct
calls debughooks->type_decl through finish_struct_1 and
rest_of_type_compilation, and within dbxout_type_decl we compute the
assembler_name for the type and nested decls. Later on, when we override the
class name when processing the typedef name for the still anonymous class, the
assembler names are not touched, and remain with incorrect name mangling.
I can't decide whether this is a problem in the C++ front end, that should call
rest_of_type_compilation only at the end of the typedef declaration, or in
dbxout, that should refrain from resolving assembler names of anonymous types
before the end of compilation, if that's at all possible. I don't know much
about stabs, so I'll leave this to someone else who does.
Reassigning to c++ in the hope that some g++ expert will chime in.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug c++/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
2010-11-20 16:06 [Bug debug/46580] New: -fcompare-debug failure with -gstabs -g due to different symbol mangling zsojka at seznam dot cz
` (2 preceding siblings ...)
2010-11-21 9:35 ` [Bug c++/46580] " aoliva at gcc dot gnu.org
@ 2021-09-20 6:06 ` pinskia at gcc dot gnu.org
2021-09-20 6:19 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-20 6:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work|5.3.0, 5.5.0, 6.1.0, 7.1.0 |
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The first testcase is fixed in GCC 5.3.0 and GCC 6+.
The second testcase is fixed in GCC 10+.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug c++/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
2010-11-20 16:06 [Bug debug/46580] New: -fcompare-debug failure with -gstabs -g due to different symbol mangling zsojka at seznam dot cz
` (3 preceding siblings ...)
2021-09-20 6:06 ` pinskia at gcc dot gnu.org
@ 2021-09-20 6:19 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-20 6:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |10.0
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The first testcase was most likely fixed by r5-9033 (r6-555 + r6-5094) which
changed where the alias managing happened.
The second testcase was most likely fixed by r10-707 which changed how the
TYPE_NAME is done for these kind of types.
^ permalink raw reply [flat|nested] 6+ messages in thread