[Bug tree-optimization/113424] New: lim fails to notice possible aliasing

[Bug tree-optimization/113424] New: lim fails to notice possible aliasing

[kristerw at gcc dot gnu.org]

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

            Bug ID: 113424
           Summary: lim fails to notice possible aliasing
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The lim pass miscompiles the following C++ program when compiled as -O3 for
x86_64 (note: it works as intended when compiled as a C program)

struct { char elt1; char bits; } *a;
char
bar (char *x, char b)
{
  if (0)
  next_bit:
    return 1;
  while (1)
    {
      if (b)
        if (a->bits)
          goto next_bit;
      *x = b;
      if (a->elt1)
        return 0;
      a = 0;
    }
}

The loop lim gets as input looks as following

  <bb 3>
  if (b_9(D) != 0)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>
  a.0_1 = a;
  _2 = a.0_1->bits;
  if (_2 != 0)
    goto <bb 7>;
  else
    goto <bb 5>;

  <bb 5>
  *x_10(D) = b_9(D);
  a.1_3 = a;
  _4 = a.1_3->elt1;
  if (_4 != 0)
    goto <bb 7>; [5.50%]
  else
    goto <bb 6>; [94.50%]

  <bb 6>
  a = 0B;
  goto <bb 3>; [100.00%]

The lim pass changes this to load `a` before the loop and uses the same value
of `a` for both accesses in bb4 and bb5, which is not correct as the store
`*x_10(D)` may have modified `a` before the access in bb5.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, this is an infinite loop with no forward progress so that might be the
difference between c and c++.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-16
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am 99% sure this is because the struct is anonymous in C++ and a's address is
not taken so it is assumed not to be used outside of the TU due to that.

Once I put a name on the struct, the "miscompiling" is gone.


Where is this reduced from because I think it is undefined C++ code.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Without a name on the struct, a becomes a local variable.

There is no aliasing issue here.

You can see the same effect in C via using:
```
static struct b1 { char elt1; char bits; } *a;

```

Since a does not have an address taken, GCC assumes (correctly), it will only
be modified from bar and will NOT be modified from an other variable/address.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

[kristerw at gcc dot gnu.org]

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

Krister Walfridsson <kristerw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #4 from Krister Walfridsson <kristerw at gcc dot gnu.org> ---
That makes sense. And it means the check for local variables I have implemented
in smtgcc need some improvements...

Anyway, to answer the question from comment 2 (which I guess is irrelevant
now): the code is a slightly modified g++.dg/opt/pr80436.C which smtgcc claimed
was miscompiled because of this issue.