[Bug c++/97474] [8/9/10/11 Regression] produces wrong code with references to another field

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
             Status|ASSIGNED                    |NEW
          Component|tree-optimization           |c++
           Assignee|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Thanks Joseph.  This means that while the proposed patch is conservative
and fixes the issue at hand it's really the C++ frontend that is wrong
in marking the parameter restrict.

Now, it might be useful to introduce a less strict definition of restrict
for this particular usecase in the frontend.  PTA for example implicitely
adds 'restrict' to the 'this' parameter of C++ CTORs (DECL_CXX_CONSTRUCTOR_P).

Leaving to C++ folks to decide.

Note that I'm not sure keying the C++ restrict adding on pointer fields in
the type works since PTA also tracks pointers through integers and thus the
following is miscompiled as well:

struct A {
    int a;
    unsigned long b;
    A(int x) : a(x), b((unsigned long)&a) {}
    A(const A& other) : a(other.a), b((unsigned long)&a) {}
    A() : a(0), b((unsigned long)&a) {}
};

int foo(A a) 
{   
    a.a *= *(int *)a.b;
    return *(int *)a.b;
}

int main() 
{   
    A a(3);
    if (foo(a) != 9)
      __builtin_abort ();
    return 0;
}

IMHO this tracking of pointers through integers is a valid restrict
optimization since extracting the "other" pointer from an integer
isn't any better to make it valid.

So if we want an "alternate restrict mode" then we have to carve another
bit out of tree_type_common (there are quite a few spare bits left).

Thoughts?