This is the mail archive of the
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: Torvald Riegel <triegel at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, nd at arm dot com, Gabriel Paubert <paubert at iram dot es>, "Bin Fan@Work" <bin dot x dot fan at oracle dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Andreas dot Krebbel at de dot ibm dot com, dje dot gcc at gmail dot com
- Date: Thu, 19 Jan 2017 16:18:39 +0100
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20161222142856.C5B931032A2@oc8523832656.ibm.com> <20161222173747.GK11295@gate.crashing.org>
On Thu, 2016-12-22 at 11:37 -0600, Segher Boessenkool wrote:
> On Thu, Dec 22, 2016 at 03:28:56PM +0100, Ulrich Weigand wrote:
> > However, there still seems to be a problem, but this time related to
> > alignment issues. We do have the 16-byte atomic instructions, but they
> > only work on 16-byte aligned data. This is a problem in particular
> > since the default alignment of 16-byte data types is still 8 bytes
> > on our platform (since the ABI only guarantees 8-byte stack alignment).
> > That's why the libatomic configure check thinks it cannot use the
> > atomic instructions when building on z, and generates code that uses
> > the separate lock. However, *if* a particular object can be proven
> > by the compiler to be 16-byte aligned, it will emit the inline
> > atomic instruction. This means there is indeed a bug if that same
> > object is also operated on via the library routine.
> > Andreas suggested that the best way to fix this would be to add a
> > runtime alignment check to the libatomic routines and also use the
> > atomic instructions in the library whenever the object actually
> > happens to be correctly aligned. It seems that this should indeed
> > fix the problem (and also use the most efficient way in all cases).
> > Not sure about Power -- adding David and Segher on CC ...
> We do not always have all atomic instructions. Not all processors have
> all, and it depends on the compiler flags used which are used. How would
> libatomic know what compiler flags are used to compile the program it is
> linked to?
I think the approach would be to require the user to always use a
suitably built libatomic that's at least as capable as the code that
will use it (e.g., see Richard Henderson's comments). Thus, if the
program uses some flags to enable a certain set of HW instructions, the
program also should use a libatomic that is built with the same (or
stronger) flags. That keeps old code working, and new code that uses
the HW instructions directly can interoperate with old code that still
If we find consensus to follow this approach, this requirement on
libatomic builds should be made explicit in the ABI spec.