Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros.

[Torvald Riegel <triegel at redhat dot com>]

On Sun, 2017-02-26 at 21:29 +0100, Florian Weimer wrote:
> * Torvald Riegel:
> 
> >> … like this, it would change the C++ name mangling of anything related
> >> to pthread_spinlock_t.  It is defined as a typedef, so the mangling
> >> uses the definition to refer to the type, not the name, according to
> >> the language rules, where typedef does not create a new type, and
> >> typedefs with the same definition can be used interchangeably.
> >
> > I'm not saying that we should change the definition to a union.  What
> > 2.14.2 in the document cited above states is that the pointers to the
> > union and the individual parts are interchangeable.  So we can use a
> > pointer to a part (ie, non-volatile) interchangeably with the pointer to
> > the union that we use internally.
> 
> The relevant quote from that document (C memory object and value
> semantics: the space of de facto and ISO standards) is:
> 
> | The standard says: 6.7.2.1p16 “The size of a union is
> | sufficient to contain the largest of its members. The value of
> | at most one of the members can be stored in a union object
> | at any time. *A pointer to a union object, suitably converted,*
> | *points to each of its members (or if a member is a bit-field,*
> | *then to the unit in which it resides), and vice versa.*” (bold
> | emphasis added).
> 
> So I think this is only valid if you actually start with a union
> object.  A plain top-level definition of a volatile int is not a union
> member, so this rule does not apply (in the “vice versa” part).

Then we'll have to agree to disagree.  What do others think about this
question?

> I think it would be much simpler to ask for a GCC extension which
> would allow us to use non-volatile access on a volatile object in a
> well-defined fashion.

I guess such an "extension" could simply be GCC promising that casts
between volatile-qualified T and non-volatile-qualified T are okay if
the object is only accessed using one of the two.