[Bug middle-end/99696] New: lto looks past aliases to initializers

[Bug middle-end/99696] New: lto looks past aliases to initializers

[rth at gcc dot gnu.org]

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

            Bug ID: 99696
           Summary: lto looks past aliases to initializers
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

The following is a c-ish version of

  const int y = init();

which no longer works with gcc 11.

The intended advantage to the program from which this is
extracted is that references to Y may be cse'd across calls.

IMO this should work fine with LTO, so long as it does not
apply the constant initializer optimization to const variables
that are aliased.

Compile: gcc -O2 -flto y?.c

--- y1.c ---
#include <assert.h>
extern const int y;
int main(void)
{
    assert(y == 1);
    return 0;
}

--- y2.c ---
static int x;
extern const int y __attribute__((alias("x")));
static void __attribute__((constructor)) init(void)
{
    x = 1;
}

[Bug middle-end/99696] lto looks past aliases to initializers

[rth at gcc dot gnu.org]

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

--- Comment #1 from Richard Henderson <rth at gcc dot gnu.org> ---
Actually, I can reproduce this with gcc 9.3 as well.
My upstream bug report simply uses gcc 11, so I assumed.

[Bug ipa/99696] lto looks past aliases to initializers

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
      Known to fail|                            |10.2.1, 11.0, 7.5.0
             Status|UNCONFIRMED                 |NEW
            Version|unknown                     |10.2.1
   Last reconfirmed|                            |2021-03-22
          Component|middle-end                  |ipa
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Honza, can you please have a look? 

The cgraph dump shows:

x/5 (x) @0x7ffff637b180
  Type: variable definition analyzed
  Visibility: prevailing_def_ironly
  References:
  Referring: y/6 (alias) init/7 (write)
  Read from file: ./a.ltrans0.o
  Availability: available
  Varpool flags:
y/6 (y) @0x7ffff637b080
  Type: variable definition analyzed alias
  Visibility: prevailing_def_ironly
  References: x/5 (alias)
  Referring: main/0 (read)
  Read from file: ./a.ltrans0.o
  Availability: available
  Varpool flags: read-only const-value-known

so indeed somehow the read-only flag is "miscomputed".

OTOH I remember that we chose to "ignore" mismatches in constness for aliases
and thus simply declare this use unsupported (there have been related
bugreports IIRC around const / non-const mixing in aliases).
Note we do not have ODR warnings for y vs. x though.