🚀 go-pugleaf

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes:
>> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> >Unsafe transformations and other optimizer bugs. As in [xxx]% cc -O4. Not
>> >to pick on [that] compiler, which is otherwise rather nice.
>> Does [Xxx]'s -O4 have bugs, or is that warning in the cc man page
>> because C programmers leave off "volatile" where it's needed?
>
>Well, the latter can't be the explanation, because their cc doesn't even
>understand volatile. Hence the former must be true.

[I'd prefer not to discuss bugs/features (the neutral word is
"behaviors") of specific products of specific companies.  Let's
confine this to a general discussion of aggerssive optimization,
please.]

There is a third possibility -- that there are at least two dialects
of pre-ANSI C; in one, global variables are volatile, in the other
they are not.  Most parts of most programs are written in the second
dialect, thought some very important parts of some very important
programs are written in the first dialect.  Lacking a standard, common
use dictates, and *both* dialects are in common use, regardless of
what the net.authorities say is "right".  (I know that sounds like a
slimy excuse, but remember who "is always right".  Note, too, that the
keyword added for ANSI was "volatile" for safety, and not "stable" for
speed.  This should give some indication of what is usually intended.)

And, whether you agree with the choice of dialects or not, it's got
nothing to do with "buggy optimizations" -- either global variables
are volatile (i.e, programs execute in serial order), or they aren't.
I believe that is what were discussing in the first place.  There's no
way to "debug" the optimization of references to global variables if
those references are intended to be treated as volatile.

David Chase
Sun Microsystems