Re: GCC optimizes integer overflow: bug or feature?

[Ian Lance Taylor <iant at google dot com>]

Matthew Woehlke <mw_triad@users.sourceforge.net> writes:

> That said, I've seen even stranger things, too. For example:
> 
> foo->bar = make_a_bar();
> foo->bar->none = value;
> 
> being rendered as:
> 
> call make_a_bar
> foo->bar->none = value
> foo->bar = <result of make_a_bar()>

That would obviously be a bug in the compiler.


> /That/ is very possible. I'm talking about /OLD/ code here, i.e. code 
> that was written back in K&R days, back before there /was/ a volatile 
> keyword. (Although I had understood that 'volatile' was a no-op in most 
> modern compilers? Does it have the semantics that loads/stores of 
> volatile variables are not re-ordered with respect to each other?)

volatile should not be a no-op in any C compiler.  volatile variables
must be accessed strictly according to the rules of the virtual
machine.  For example, if the code reads the variable twie, the
program must read the variable twice; it can't cache the value after
the first read.  volatile variables are reasonably useful for
accessing memory mapped devices, in which the memory may change in
ways which the compiler does not see.  They are not particularly
useful, by themselves, for multi-processor systems, because they
provide no guarantees about synchronization between processors.


> >   And relying on a library call to act as a memory barrier is risky.
> > [snip]
> > Now, the compiler *does* know not to optimise moves across library calls, but
> > you're investing too much trust in them if you think the CPU's internal units
> > know or care whether you're in a libcall or your mainline code.
> 
> You're preaching to the choir. Unfortunately adding proper assembly 
> modules to our build system didn't go over so well, and I am /not/ going 
> to try to write inline assembler that works on six-or-more different 
> compilers. :-) So I know this is just a 'cross your fingers and hope it 
> works' approach on non-x86 platforms. On x86 I use the correct, 
> previously-quoted inline assembly, which as mentioned acts as a barrier 
> for both the compiler /and/ the CPU. As you say, all it's really 
> ensuring in other cases is that the compiler remains honest, but that 
> was the intent, and I know it isn't perfect.

Current versions of gcc provide a set of synchronization primitives
which may help write code which works correctly on multi-processor
systems.

Ian