[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

--- Comment #28 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 11 08:40:59 2017
New Revision: 244304

URL: https://gcc.gnu.org/viewcvs?rev=244304=gcc=rev
Log:
PR middle-end/50199
* lto-lang.c (lto_post_options): Force flag_merge_constants = 1
if it was 0.

* gcc.dg/lto/pr50199_0.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr50199_0.c
Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

--- Comment #27 from Richard Biener  ---
works for me

[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #26 from Jakub Jelinek  ---
Created attachment 40491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40491=edit
gcc7-pr50199.patch

Untested workaround.

[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

--- Comment #25 from rguenther at suse dot de  ---
On Tue, 10 Jan 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
> 
> --- Comment #24 from Jakub Jelinek  ---
> Another option is to silently force -flto-partition=none (or would
> -flto-partition=1to1 work too?) if !flag_merge_constants or HAVE_GAS_SHF_MERGE
> is not defined.  Or silently turn on flag_merge_constants (set to 1 if 0) in
> lto compilation, and/or force -flto-partition=none (or 1to1) if
> HAVE_GAS_SHF_MERGE is not defined.
> Honza/Richard, what do you prefer here?

I prefer handling constants correctly, forcing STRING_CSTs to only appear
via CONST_DECL DECL_INITIAL and putting CONST_DECLs into a symbol-table
like constant pool on the cgraph level.

That's quite some work and the question is whether this bug is important
enough to warrant a fix like you propose.  Of your proposals I prefer
forcing -fmerge-constants (and/or simply documenting the restriction
of LTO when working w/o constant merging).

At some point I started the _CST -> _DECL thing (I have
partial patches somewhere) but there was some fallout I didn't fully
address.

The issue with LTO is that we fail to merge in-TU constants because
we have those _CSTs and tear apart the TU.

So - force flag_merge_constants to 1 if in_lto_p?  Or do that from
lto-wrapper, diagnosing that we do that?

[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

--- Comment #24 from Jakub Jelinek  ---
Another option is to silently force -flto-partition=none (or would
-flto-partition=1to1 work too?) if !flag_merge_constants or HAVE_GAS_SHF_MERGE
is not defined.  Or silently turn on flag_merge_constants (set to 1 if 0) in
lto compilation, and/or force -flto-partition=none (or 1to1) if
HAVE_GAS_SHF_MERGE is not defined.
Honza/Richard, what do you prefer here?

[Bug middle-end/50199] [5/6/7 Regression] wrong code with -flto -fno-merge-constants

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |5.5

--- Comment #23 from Richard Biener  ---
GCC 4.9 branch is being closed