Another apparently little-known GCC fact
GCC supports a
-pthread option on several platforms, which causes
the necessary options for using POSIX threads to be passed
to the preprocessor, compiler and linker.
In particular, for
GNU/Linux on x86 -pthread passes
-D_REENTRANT to the preprocessor and -lpthread
to the linker.
The documentation for GCC
options doesn't currently mention -pthread
except for a few specific architectures. The reasons for
this are lengthy, but not very good.
On Solaris, GCC used to only support the -pthreads
option,
which is how Sun's compiler spells it, but in recent
versions of GCC -pthread has the same effect.
(I might post other little-known GCC facts here, in the vain
hope it will disseminate the information more widely.)
Bicycle sheds
There is a noisy thread currently taking place on the GCC
mailing list arguing over whether compiler optimisations
that result in speculative loads are valid in multithreaded
programs. Several people have made mistaken claims about
guarantees made by POSIX (there are almost none) and others
have
argued from personal opinion. A few have argued from
positions which are technically correct, but incompatible
with the proposed
C++ memory model. Very few of the participants
seem to have bothered to read the link I first posted
several days ago and aph re-posted yesterday: N2338:
Concurrency memory model compiler consequences. When the
authors of the proposed memory model take the time to
spell out how the issues affect compilers, you'd hope people
would read it before pontificating on that very subject.
The discusion has spilled over to LKML and (among
others) Ian Lance Taylor's blag, which has been required
reading for me since his series on linkers.
Unfortunately, despite all the apparent experts on the GCC list
arguing about whether particular examples are valid without
locks or memory barriers, noone seems interested in
reviewing my patch
to improve the use of memory barriers in GCC's
shared_ptr. Maybe it would get more attention if I
argued from personal conviction and dogma rather than trying
to write correctly synchronised code using the right
barriers ;-)