http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-04
15:42:18 UTC ---
(In reply to comment #21)
> Reopened, the fix breaks LTO bootstrap with Ada:
>
> /tmp/cc5Nhl9J.s: Assembler messages:
> /tmp/cc5Nhl9J.s:6206: Error: symbol `.LC0' is already defined
> /tmp/cc5Nhl9J.s:6219: Error: symbol `.LC0' is already defined
> /tmp/cc5Nhl9J.s:6996: Error: symbol `.LC0' is already defined
> make[4]: *** [/tmp/ccuFb8kg.ltrans2.ltrans.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
> /tmp/ccf05Tt7.s: Assembler messages:
> /tmp/ccf05Tt7.s:5618: Error: symbol `.LC5' is already defined
> /tmp/ccf05Tt7.s:5629: Error: symbol `.LC5' is already defined
> make[4]: *** [/tmp/ccuFb8kg.ltrans8.ltrans.o] Error 1
> lto-wrapper: make returned 2 exit status
> /home/eric/install/gcc/x86_64-suse-linux/bin/ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[3]: *** [gnatbind] Error 1
> make[3]: *** Waiting for unfinished jobs....
>
> The reason for the name collision seems obvious enough... I still think the
> best solution is not to fiddle with the alignment of DECL_IN_CONSTANT_POOL
> objects at this point, since the machinery assumes that their alignment
> doesn't
> matter (or more precisely that they only need to have the alignment of their
> type, which is correct as far as I know).
How can the patch cause a name collision when all the patch does is
avoid creating a new decl...? They are static and thus should be
mangled.
Well, and if we want a new decl just to re-assign a unique name here
then we want to copy over alignment information. That is, LTO should
handle constant-pool entries by _not_ streaming the decl then. Honza,
how are those supposed to make the symtab -> WPA -> LTRANS transition
anyway?
