[Bug c/65752] Too strong optimizations int -> pointer casts

gcc at robbertkrebbers dot nl gcc-bugzilla@gcc.gnu.org
Tue Apr 14 09:23:00 GMT 2015


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

--- Comment #8 from Robbert <gcc at robbertkrebbers dot nl> ---
(In reply to Richard Biener from comment #7)
> Other testcase:
> 
> int main()
> {
>   int *p;
>   int x = 0;
>   if (p == &x)
>    *p = 1;
>   return x;
> }
> 
> we optimize this to return 0.  You probably wouldn't consider that invalid I
> guess?
This is undoubtedly undefined behavior, an indeterminate pointer is used in a
comparison ==.

But even in the more controversial

int main() {
  int x = 0, y, *p = &y + 1;
  if (p == &x) { printf("compared succeeded"); *p = 1; }
  return x;
}

I am fine with any of the following behaviors:
* Nothing is printed, 0 is returned
* "compared succeeded" is printed, 0 is returned
* "compared succeeded" is printed, 1 is returned
And anything else because it has undefined behavior. Here a pointer p whose
origin/provenance does not involve its representation is used out of its
bounds.

The point is that when performing a pointer-to-int cast or when fiddling with
object representations of pointers, the representation of the pointer has
become transparent and *abstraction is broken* (generally deliberately!). One
could have gathered information to reconstruct the pointer in some other
context and then the compiler should not perform unexpected formalizations.



More information about the Gcc-bugs mailing list