https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
Bug ID: 89479 Summary: __restrict Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz at technion dot ac.il Target Milestone: --- (This is all illustrated at: https://godbolt.org/z/nz2YXE ) Let us make our language C++17. Consider the following function: int foo(const int* x, void g()) { int result = *x; g(); result += *x; return result; } since we have no aliasing guarantees, we must assume the invocation of g() may change the value at address x, so we must perform two reads from x to compute the result - one before the call and one after. If, however, we add __restrict__ specifier to x: int bar(const int* __restrict__ x, void g()) { int result = *x; g(); result += *x; return result; } we may assume x "points to an unaliased integer" (as per https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html ). That means we can read from address x just once, and double the value to get our result. I realize there's a subtle point here, which is whether being "unaliased" also applies to g()'s behavior. It is my understanding that it does. Well, clang 7.0 understands things they way I do, and indeed optimizes one of the reads away in `bar()`. But - g++ 8.3 (and g++ "trunk", whatever that means on GodBolt) doesn't do so, and reads _twice_ from x both in `foo()` and in `bar()`.