On 10/26/2010 4:05 PM, Peter Lawrence wrote:On 10/26/2010 4:05 PM, Peter Lawrence wrote:
Your objection is like saying that it isn't kosher to ignore the
"register" keyword, because
"I know what I am doing and you don't.....".
What isn't kosher, is making side effects disappear from a C program.
to have a valid complaint you have to demonstrate a program
behaves incorrectly when compiled with LLVM,
Else-thread, Duncan Sands has confirmed that sufficiently earlier versions *did* violate C90/C99, but ToT appears to be volatile-correct for the slightly over-complicated true program (as might be expected from John Regehr's work).
are you going to also complain if "register volatile" variables get
Yes. Intentional violations of the C and C++ standards by CLang, DragonEgg, and llvm-gcc should be explicitly documented, period. AFAIK these have not been (confirmation by a lead developer on mailing-list is pretty obscure, this should be in the main documentation). Pointers to refuting documentation in releases welcome.
..., because we both know that something in a
general purpose register can't possibly be a memory-mapped IO device
interface with side effects.
Which doesn't mean anything to a full-blown emulation.
LLVM is simply extending that logic to
local stack frame variables.
As a matter of LLVM IR, no problem. With total control of the virtual machine, this optimization is reasonable. (It just means that a volatile C local stack frame variable cannot be represented accurately, as a volatile LLVM IR local stack frame variable.)
As a matter of C, or C++ : this is fine *if* it is explicitly documented, as an intentional exception to language standard conformance. I view this to be a documentation bug in affected releases, not a compiler bug.