This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/54095] Unnecessary static variable renaming
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Jul 2012 08:46:04 +0000
- Subject: [Bug lto/54095] Unnecessary static variable renaming
- Auto-submitted: auto-generated
- References: <bug-54095-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2012-07-26
CC| |hubicka at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-26 08:46:04 UTC ---
Confirmed. My overall plan was to delay assigning an assembler name (or just
delay the mangling) until LTRANS phase where we will know if partitioning
resulted in a conflict of two static decls from different TUs.
It's been on my todo list for some time ... ;)
Btw, this re-naming also confuses debugging - you can no longer do
(gdb) p foo
but have to do
(gdb) p foo.2353.2353
ugh.
Note that you'll not be able to rely on statics not being renamed
apart from when you use 1to1 partitioning (well, hopefully - I think
we still pull in inlines which might pull in conflicts).