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