This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] Use pthread effective-target in testsuite
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Thu, 15 Jun 2017 12:17:50 +0100
- Subject: Re: [v3] Use pthread effective-target in testsuite
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 10D5480B56
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 10D5480B56
- References: <yddvanx62bc.fsf@CeBiTec.Uni-Bielefeld.DE>
On 15/06/17 11:13 +0200, Rainer Orth wrote:
I've recently been reminded that the pthread tests in libstdc++ still
use insanely long lists of targets to control where they are run. I'd
several times promised to do something about that, and here's the patch
that finally does.
The patch is mostly mechanical (and those parts were produced by a short
perl script), but a couple of issues bear comments or pose questions:
* For all tests using -pthread, I've removed the target lists from both
dg-do run and dg-options, replacing them by
dg-require-effective-target pthread instead.
* 4 tests in 30_threads/shared_mutex use -std=gnu++17 in addition to
-pthread, but in a weird way: most targets use both options, but three
(*-*-darwin*, *-*-cygwin, *-*-rtems) only pass -std=gnu++17. I've no
idea why and think this is unnecessary:
** Darwin is just a regular pthreads target, so this should work just
fine.
** Cygwin (and MingW) both understand -pthread as well. If there's some
reason *not* to use it here, it should be explained in the tests and
made explicit.
** RTEMS just ignores -pthread according to gcc/config/rtems.opt, so we
should be fine with just passing it anyway.
Looks good, thanks for the analysis.
* The two forced_unwind.cc tests are GNU specific (__forced_unwind
exception) and time out on Solaris when I tried, so I've left the
target list as is. I've just removed the target list from dg-options
(which is unnecessary duplication and incorrectly included
*-*-solaris* in one case) and added the pthread effective-target
although that's not strictly necessary.
OK.
* In 30_threads/this_thread/57060.cc I've moved the c++11 requirement to
dg-require-effective-target for symmetry.
Nice.
Two testcases I've left alone:
* 18_support/bad_exception/23591_thread-1.c requires -ftable-verify
support; one could add the pthread effective target and eventually
replace the explicit (possibly incomplete) target list, but that's for
another time.
* ext/mt_allocator/22309_thread.cc is currently restricted to
*-*-linux*, *-*-gnu*, but I don't immediately see why it couldn't work
on other targets with dlopen and friends.
OK, leaving them alone is fine.
I've refrained from creating a 200+ entry ChangeLog entry for the
mechanical part, but could do so if required.
No, this is fine.
Bootstrapped without regressions on i386-pc-solaris2.12,
sparc-sun-solaris2.12, and x86_64-pc-linux-gnu.
Did some limited testing on x86_64-apple-darwin16.7.0, but Darwin
testing is currently massively hampered by PR bootstrap/81033.
Ok for mainline?
Yes please. This makes me very happy, thank you!