Re: glibc 2.21 - Machine maintainers, please test your machines.

[Torvald Riegel <triegel at redhat dot com>]

[Note that I don't have a strong opinion in either direction regarding
this.  I just want to make sure there's no misunderstanding here and
everyone knows why we decide either way (and agrees with the decision).]

On Mon, 2015-01-26 at 16:52 +0100, Andreas Schwab wrote:
> Torvald Riegel <triegel@redhat.com> writes:
> 
> > On Mon, 2015-01-26 at 16:03 +0100, Andreas Schwab wrote:
> >> The compiler can simplify operations based on the known alignment of
> >> objects.  This is like any other undefined behaviour.
> >
> > Is your concern regarding glibc code (ie, sem_*()) or code outside
> > glibc?
> 
> It doesn't matter.  If you have a type with 8 byte alignment, but the
> object has only 4 byte alignment you get undefined behaviour.

Well, but we control the glibc code and to some extent it's compilation
(if we assume no LTO, at least).  It seems HJ is claiming that while his
change could be undefined behavior, it is harmless for x32 with the
compiler we currently support.

> > For code outside of glibc, I'm not sure something can actually happen.
> > If an application picks up the new semaphore.h, sem_t will be
> > 8B-aligned.  If not, then not.  I don't think this can be partially
> > 8B/4B-aligned, or can it?
> 
> You are changing the ABI.  Anything can happen.

I agree we change the ABI.  Just to clarify though, your concern is thus
specifically due to ABI changes of sem_t and what they would do in user
programs (e.g., if a sem_t is part of another struct whose alignment
changes in return) -- and not regarding how glibc code could fail if
presented with a non-8B-aligned sem_t?