It’s possible to reason this is prevented by the aliasing rules, but this causes inconsistency with the rest of the standard, which explicitly allows type-punning through unions (which should likewise be disallowed under this interpretation, through the same reasoning). The standard would need an explicit change to cover both situations in the intended manner.

I think neither the compilers nor the verifiers are buggy — it’s the standard that needs a fix. I disagree with Dan that it’s “impossible” to have sound rules (at the very least, every compiler implementation at a particular optimization level, however obtuse, represents one consistent implementation of a set of rules, however complicated), but the fix in this case would be complicated and inelegant — pointers to union members would need special treatment, likely causing a lot of ugly adjustments to sections that have nothing to do with unions.

for (bool go = true; go; (go = (f != l)) && (++f, true)) {
use(f);
}

// or

do {
use(f);
} while ((f != l) && (++f, true));

// or my favorite which only works in C++ because stupid C99 doesn’t allow variables to be defined in the if expression

#define inclusive_for(init, cond, inc) \
if (bool ar3_d0n3_ = false) {} \
else for (init; !ar3_d0n3_; (ar3_d0n3_ = !(bool)(cond)) || ((inc), false))

inclusive_for (int i = INT_MIN, i != INT_MAX, ++i) {
use(f);
}

Also, -fstrict-aliasing is enabled for -O2 but not -O1. I imagine that if you used -fstrict-aliasing without a -O flag, you’d have the same problem.

http://open-std.org/JTC1/SC22/WG14/www/docs/dr_236.htm

This report is categorized as Closed, however the explanation in the Committee Response is based on reasoning which isn’t obviously supported by the standard.

In general, there does not appear to be any way to have sound type-based aliasing rules in a language that also has non-discriminated unions, untyped (e.g. malloc) memory, and pointers. However, type-based alias rules are considered an important feature, and the committee has chosen to keep it anyway. Consequently, the standard is inconsistent. In practice, each compiler is left to choose for itself the extent to which it is willing to trade safety for optimization.

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542

int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}

The difference is that John’s program reads through the union with fn2 (b.f0);