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: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 04 Jan 2012 13:02:26 +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 #9 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-04 13:02:26 UTC ---
On Wed, 4 Jan 2012, hubicka at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
>
> --- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-04 12:57:28 UTC ---
> I agree that ignoring the bug or adding sorry refusing -fno-merge-constants
> -flto is probably only way to deal with it in 4.7.
>
> If we go the way translating into initialized vars, we probably could translate
> string constants as easilly as const_decls, so perhaps there is no frontend
> change needed at all.
>
> In general it would be very useful to have pass tagging ADDR_EXPRs on whether
> the address of object taken needs to be unique or can change freely. This would
> be useful at several places in IPA and also we could then only promote some of
> the const decls.
Well, whether or not is the Frontends burden to decide. And if not,
it has to use an ADDR_EXPR of a CONST_DECL.
Richard.