This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: mrs at apple dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 28 Nov 05 13:55:35 EST
- Subject: Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)
He said we can do anything, this is untrue. I rail against the casual
use of the word because it misleads others into believing it, and then
proposing patches that do anything they want, and yet make gcc worse.
I realize there that we have no documentation person that writes down
everything religiously and that from time to time, people that should
write documentation, don't. I'm just as guilty (or more so) as
everyone else. Realize, some consider that just a simple
documentation bug, not an opportunity to go messing with a fine compiler.
It's not that simple and I suspect you know it. The things that aren't
written down are the "contract" between the programmer and the compiler
about what the latter is guaranteeing to the former. It's nice to say
that a compiler won't ever make a change that won't break *any* program,
but that's impossible. Even the slightest change can "break" a program
that relies on an uninitialized variable, for example. Obviously, we
understand that's permissible because such a program is "not correct"
or "erroneous". But the problem in extending that doctrine is that we
have to know which programs are erroneous and when there's no precise
documentation of the language in which they're written (GNU C),
there's no way to say with certainty whether a program is or not.
So there's no way to know whether the set of programs that a given
change will break consists of just erroneous programs. One can take
the very conservative approach of avoiding that problem by not making
*any* changes that could conceivably break a program, but that would mean
making no progress on improving a "fine compiler".