public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Disable -Wrestrict for two nptl/tst-attr3.c tests [committed]
@ 2017-12-18 22:56 Joseph Myers
  2017-12-19  9:48 ` Florian Weimer
  0 siblings, 1 reply; 3+ messages in thread
From: Joseph Myers @ 2017-12-18 22:56 UTC (permalink / raw)
  To: libc-alpha

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.

diff --git a/nptl/tst-attr3.c b/nptl/tst-attr3.c
index bc23386..420a7db 100644
--- a/nptl/tst-attr3.c
+++ b/nptl/tst-attr3.c
@@ -26,6 +26,7 @@
 #include <unistd.h>
 
 #include <stackinfo.h>
+#include <libc-diag.h>
 
 static void *
 tf (void *arg)
@@ -362,7 +363,16 @@ do_test (void)
       result = 1;
     }
 
+  DIAG_PUSH_NEEDS_COMMENT;
+#if __GNUC_PREREQ (7, 0)
+  /* GCC 8 warns about aliasing of the restrict-qualified arguments
+     passed &a.  Since pthread_create does not dereference its fourth
+     argument, this aliasing, which is deliberate in this test, cannot
+     in fact cause problems.  */
+  DIAG_IGNORE_NEEDS_COMMENT (8, "-Wrestrict");
+#endif
   err = pthread_create (&th, &a, tf, &a);
+  DIAG_POP_NEEDS_COMMENT;
   if (err)
     {
       error (0, err, "pthread_create #2 failed");
@@ -388,7 +398,16 @@ do_test (void)
       result = 1;
     }
 
+  DIAG_PUSH_NEEDS_COMMENT;
+#if __GNUC_PREREQ (7, 0)
+  /* GCC 8 warns about aliasing of the restrict-qualified arguments
+     passed &a.  Since pthread_create does not dereference its fourth
+     argument, this aliasing, which is deliberate in this test, cannot
+     in fact cause problems.  */
+  DIAG_IGNORE_NEEDS_COMMENT (8, "-Wrestrict");
+#endif
   err = pthread_create (&th, &a, tf, &a);
+  DIAG_POP_NEEDS_COMMENT;
   if (err)
     {
       error (0, err, "pthread_create #3 failed");

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Disable -Wrestrict for two nptl/tst-attr3.c tests [committed]
  2017-12-18 22:56 Disable -Wrestrict for two nptl/tst-attr3.c tests [committed] Joseph Myers
@ 2017-12-19  9:48 ` Florian Weimer
  2017-12-19 13:55   ` Joseph Myers
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2017-12-19  9:48 UTC (permalink / raw)
  To: Joseph Myers, libc-alpha

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Disable -Wrestrict for two nptl/tst-attr3.c tests [committed]
  2017-12-19  9:48 ` Florian Weimer
@ 2017-12-19 13:55   ` Joseph Myers
  0 siblings, 0 replies; 3+ messages in thread
From: Joseph Myers @ 2017-12-19 13:55 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-alpha

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-12-19 13:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-18 22:56 Disable -Wrestrict for two nptl/tst-attr3.c tests [committed] Joseph Myers
2017-12-19  9:48 ` Florian Weimer
2017-12-19 13:55   ` Joseph Myers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).