[Bug c/48885] missed optimization with restrict qualifier?

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #18 from vries at gcc dot gnu.org ---
Let's rewrite the example from comment 14 to plain C (as we did in PR67705):

void
f (int *__restrict__ *__restrict__ fpp, int *fp2)
{
  int *fp = *fpp;
  *fp = 1;
  *fp2 = 2;
}

void
g (int *__restrict__ gp)
{
  f (&gp, gp);
}

void
h (void)
{
  int ha;
  g (&ha);
}

My interpretation of the restricts in the example (given what I've learned in
PR67705):

Restrict declaration D: "int *__restrict__ gp"
Type T: int
Object P: gp
Block B: g function block
Lvalues: *fp and *fp2
Objects designated by lvalues: ha in both cases.
Object ha modified during execution of B: yes
Object gp considered modified during execution of B: yes
&Lvalues: pointer expressions fp and fp2
&Lvalues based on object P: yes
Conclusion: Valid example.  Since both lvalues have their address based on
            the same restrict pointer, there are no disambiguation
            consequences.

Restrict declaration D: "int *__restrict__ *__restrict__ fpp"
Type T: int *__restrict__
Object P: fpp
Block B: f function block
Lvalues: *fpp
Objects designated by lvalues: gp
Object gp modified during execution of B: considered modified, yes
Object fpp considered modified during execution of B: yes
&Lvalues: pointer expression fpp
&Lvalues based on object P: yes
Conclusion: Valid example. Since there's only one lvalue accessing gp there
            are no disambiguation consequences.

Joseph, can you confirm that:
- this is a valid example, and
- there are no disambiguation consequences.

If that is indeed the case, then the committed patch is invalid.