This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
- 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, 08 Dec 2011 14:37:14 +0000
- Subject: [Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
- Auto-submitted: auto-generated
- References: <bug-50199-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-08 14:37:14 UTC ---
Which means - taking addresses of literals should be disallowed (that
includes the prominent example of STRING_CSTs, but possibly that is not
the only existing case?). Instead when a literal needs its address taken
it needs to be put into a CONST_DECL of which we can take the address
(thus, entered into the "constant pool"). Those CONST_DECLs should be
entered into the varpool so that we properly partition them with LTO.
The C frontend is probably the oldest and most prominent offender
of creating ADDR_EXPR <STRING_CST>.
GIMPLE-side "fix":
Index: gimple.c
===================================================================
--- gimple.c (revision 182107)
+++ gimple.c (working copy)
@@ -2903,9 +2903,7 @@ is_gimple_id (tree t)
return (is_gimple_variable (t)
|| TREE_CODE (t) == FUNCTION_DECL
|| TREE_CODE (t) == LABEL_DECL
- || TREE_CODE (t) == CONST_DECL
- /* Allow string constants, since they are addressable. */
- || TREE_CODE (t) == STRING_CST);
+ || TREE_CODE (t) == CONST_DECL);
}
(and watch it explode, obviously)
Probably not 4.7 material to change though.