This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/48668] New: [4.6/4.7 regression] COMDAT Group signature not emitted in group
- From: "ro at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 18 Apr 2011 17:00:17 +0000
- Subject: [Bug middle-end/48668] New: [4.6/4.7 regression] COMDAT Group signature not emitted in group
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48668
Summary: [4.6/4.7 regression] COMDAT Group signature not
emitted in group
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: ro@gcc.gnu.org
CC: hubicka@gcc.gnu.org
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
I'm currently putting the finishing touches to the COMDAT-with-as patch
[build, c++, lto] Support COMDAT group with Sun as (PR target/40483)
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01365.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00600.html
When I retested the patch on mainline, I found that there's a single
regression:
FAIL: g++.dg/opt/thunk2.C (test for excess errors)
WARNING: g++.dg/opt/thunk2.C compilation failed to produce executable
Excess errors:
Assembler: thunk2.C
"/var/tmp//ccLuaW10.s", line 219 : Group Id symbol defined outside of group
This error didn't happen when I originally developed the patch based on GCC
4.5.
Sun as is right, though: the signature symbol _ZN1U3fooEi (U::foo(int)) is
defined inside a group with signature _ZThn4_N1U3fooEi (non-virtual thunk to
U::foo(int)). The same happens with gas, which seems to be far more lazy
accepting stuff like this.
A reghunt revealed that this regression was introduced by this patch:
2010-09-29 Jan Hubicka <jh@suse.cz>
* cgraphunit.c (assemble_function): Output thunks and aliases before
the function itself.
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00354.html
I don't think that the submission contains enough justification for this, and
the result seems to be plain wrong.
I'm attaching the assembler output (with gas since the affected patch isn't
yet integrated) without and with the patch.
It seems like the easiest fix would be to just revert the patch.