Ian,

Now I guess I should apologize to youfor using the word `condescending'.
In the context of tech-toolchain, I assumed we'd all understand the 
impact of assuming all memory objects are killed by any write through
a pointer, versus the strict-aliasing model.

I agree the specific example cited can be recoded simply, there's a
**lot** of naive-C polymorphism embedded in kernels, and other
pre-C99/ISO-C codebases, which isn't at all easy to recode in a
fully-ANSI-C standards-conformant way.

I agree with you that its a culture-clash issue. I've been using (and
once, contributing) to gcc for a long time, and I'd much, much rather
have -fstrict-aliasing default to off (even for -O2) uniess `-ansi' is
also specified.  That should be acceptable to the standards-weenies:
it preserves least-surprise that gcc doesn't enforce strict ANSI
semantics unless it's *told* the input code is strictly ANSI conformant.
I'd even suggest that to the GCC maintainers, but there's only so many
hours in a day. (Trogolodyte though I may be, a netbsd-specific change
to that effect would probably cause even more confusion.)

I guess I see "-O2 implies-aliasing" as a change to the GCC dialect of
C; and now the gcc maintainers are blaming the users of the (old)
language for the downsides of that change. Looked at that way, it
leaves a rather unpleasant taste in one's mouth.

(Again, having hung out with some of the folks in Monica Lams group, I
really _do_ understand the temptation to exploit the "undefined"
behaviour to do more optimization. At least we can turn it off in
kernel config files :-/)