Re: -fno-tree-cselim not working?

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

"Andrew Pinski" <pinskia@gmail.com> writes:

> And it is not a new problem, if conversion has
> been with GCC since the 2.95 days so I don't understand why it is only
> being brought up now (except threading programming is becoming more
> popular).  And really I still say these are thread safe, just not the
> way you think of them being thread safe.

Misunderstanding of what code is thread safe is common, because the
abstract memory model in the language standard does not conform to
people's nÃive assumptions about memory accesses.  People assume that
memory will be accessed more or less as described in the code, but of
course the standard has no such requirement.  The standard permits
just about anything, including, e.g., promoting globals to register
variables.

The standard gives exactly one out, which is that volatile requires
the compiler to implement the nÃive memory model.  Unfortunately that
is not what most people want either.

Until the C++0x memory model is implemented, people writing code that
has to be thread safe need to use memory barriers around reads and
writes to shared data.  There is no standard approved way to implement
a memory barrier, but acquiring or releasing a mutex should do it.

And even memory barriers do not suffice if you are accessing
bitfields, or, in general, fields in a struct which are smaller than
int.  This can break if you want to use different mutexes to protect
different fields in the struct.  The compiler may modify such fields
using a read-partial modify-write cycle which will silently change
adjacent fields in the struct.

There are lots of problems with multi-threaded C/C++ code and few good
solutions.

It would be nice to figure out how gcc could improve matters.  The
answer is not going to be to disable certain optimizations.  But
perhaps we should implement the draft C++0x memory model for both C
and C++.

Ian