Disable -Wrestrict for two nptl/tst-attr3.c tests [committed]

  nptl/tst-attr3 fails to build with GCC mainline because of
(deliberate) aliasing between the second (attributes) and fourth
(argument to thread start routine) arguments to pthread_create.

Although both those arguments are restrict-qualified in POSIX,
pthread_create does not actually dereference its fourth argument; it's
an opaque pointer passed to the thread start routine.  Thus, the
aliasing is actually valid in this case, and it's deliberate in the
test.  So this patch makes the test disable -Wrestrict for the two
pthread_create calls in question.  (-Wrestrict was added in GCC 7,
hence the __GNUC_PREREQ conditions, but the particular warning in
question is new in GCC 8.)

Tested compilation with build-many-glibcs.py for aarch64-linux-gnu.  
Committed.

2017-12-18  Joseph Myers  <joseph@codesourcery.com>

	* nptl/tst-attr3.c: Include <libc-diag.h>.
	(do_test) [__GNUC_PREREQ (7, 0)]: Ignore -Wrestrict for two tests.
  

On 12/18/2017 11:56 PM, Joseph Myers wrote:
> nptl/tst-attr3 fails to build with GCC mainline because of
> (deliberate) aliasing between the second (attributes) and fourth
> (argument to thread start routine) arguments to pthread_create.
> 
> Although both those arguments are restrict-qualified in POSIX,
> pthread_create does not actually dereference its fourth argument; it's
> an opaque pointer passed to the thread start routine.  Thus, the
> aliasing is actually valid in this case,

I think the restrict requirements extend to called functions as well, 
due to the way the execution of a block is defined in C11 (“an execution 
of [a block] B means that portion of the execution of the program that 
would correspond to the lifetime of an object with scalar type and 
automatic storage duration associated with B”).

The proper fix seems to be to remove the restrict qualifier from the 
last argument of pthread_create, considering that the thread start 
routine argument lacks the restrict qualifier, too.

Thanks,
Florian
  

On Tue, 19 Dec 2017, Florian Weimer wrote:

> On 12/18/2017 11:56 PM, Joseph Myers wrote:
> > nptl/tst-attr3 fails to build with GCC mainline because of
> > (deliberate) aliasing between the second (attributes) and fourth
> > (argument to thread start routine) arguments to pthread_create.
> > 
> > Although both those arguments are restrict-qualified in POSIX,
> > pthread_create does not actually dereference its fourth argument; it's
> > an opaque pointer passed to the thread start routine.  Thus, the
> > aliasing is actually valid in this case,
> 
> I think the restrict requirements extend to called functions as well, due to
> the way the execution of a block is defined in C11 (“an execution of [a block]
> B means that portion of the execution of the program that would correspond to
> the lifetime of an object with scalar type and automatic storage duration
> associated with B”).

This may be another case of glibc (and tests) being written as C with ABI 
boundaries, so that how pthread_create calls the function is invisible.  
I also don't think the restrict qualifiers on parameters in headers have 
any inherent semantic significance in the caller; the warning is 
heuristically supposing that the definition of the function has the same 
qualifiers.  But as long as the thread start function doesn't modify the 
object pointed to by its argument it doesn't matter; the aliasing is OK 
for unmodified objects.

> The proper fix seems to be to remove the restrict qualifier from the last
> argument of pthread_create, considering that the thread start routine argument
> lacks the restrict qualifier, too.

The qualifier comes from POSIX.  Though as such qualifiers don't affect 
type compatibility, there's no way for a conforming program to tell 
whether the qualifier is present or not.