[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