[Bug middle-end/71062] New: [bugzilla] r235622 and restrict pointers

["andre.simoesdiasvieira at arm dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 71062
           Summary: [bugzilla] r235622 and restrict pointers
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andre.simoesdiasvieira at arm dot com
  Target Milestone: ---

Hi there,

I have encountered a new FAIL when testing newlib-nano for the arm-none-eabi
toolchain which I believe is caused by a change in code generation for
freopen.c.

After some investigation I was able to trace the issue back to a pointer
comparison with a restrict qualified pointer. See below a small piece of code
that illustrates the issue.

$cat t.c
extern const char bar;

int
foo (register char *__restrict p)
{
  if (p == &bar)
    return 1;

  return 0;
}

Since revision r235622, the pointer comparison here is evaluated to false
during compilation and the whole basic block is optimized away.

After some inner struggle and quite a few passes over the restrict definition
in the C99 standard(Committee Draft -- April 12, 2011, N1570) I think this
assumption that p and &bar can't point to the same object might be invalid.

Yes, the C-standard defines the '&' operator to yield a pointer to the object.
Though the formal definition of restrict only seems to apply to the
dereferencing of pointers. In this case, we do not dereference the pointer
created by '&bar' and thus do not access the object that 'p' might be pointing
to.

Does my reasoning make sense? I find it quite difficult to wrap my head around
the definition of restrict.

Cheers,
Andre