Re: GCC optimizes integer overflow: bug or feature?

[Seongbae Park]

On 12/20/06, Dave Korn <address@hidden> wrote:
...
> > We (in a major, commercial application) ran into exactly this issue.
> > 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
> > (it is a barrier across which neither the compiler nor CPU will reorder
> > things). Failing that, no-op cross-library calls (that can't be inlined)
> > seem to do the trick.
>
>   This simply means you have failed to correctly declare a variable volatile
> that in fact /is/ likely to be spontaneously changed by a separate thread of
> execution.

The C or C++ standard doesn't define ANYTHING related to threads,
and thus anything related to threads is beyond the standard.
If you think volatile means something in an MT environment,
think again. You can deduce certain aspect (e.g. guaranteed
appearance of store or load), but nothing beyond that.
Add memory model to the mix, and you're way beyond what the language says,
and you need to rely on the non-standard non-portable facilities,
if provided at all.
Even in a single threaded environment, what exactly volatile means
is not quite clear in the standard (except for setjmp/longjmp related aspect).

I liked the following paper (for general users,
not for the compiler developers, mind you):

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";