public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/66005] New: libgomp make check time is excessive
@ 2015-05-04 13:38 ro at gcc dot gnu.org
2022-01-21 20:42 ` [Bug libgomp/66005] " belyshev at depni dot sinp.msu.ru
` (31 more replies)
0 siblings, 32 replies; 33+ messages in thread
From: ro at gcc dot gnu.org @ 2015-05-04 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Bug ID: 66005
Summary: libgomp make check time is excessive
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
Target Milestone: ---
With all those OpenACC tests having been added to the libgomp testsuite, make
check times have skyrocketed on the gcc 5 branch and mainline:
On a reasonably fast x86 machine, it takes 4286 seconds:
Test Run By ro on Sat May 2 00:56:49 2015
runtest completed at Sat May 2 02:08:15 2015
while e.g. on slower sparc boxes we're at 29406 seconds:
Test Run By ro on Fri May 1 18:38:07 2015
runtest completed at Sat May 2 02:48:13 2015
while for 4.9 we had only 7825 seconds:
Test Run By ro on Sat May 2 17:20:23 2015
runtest completed at Sat May 2 19:30:48 2015
Being sequential, the libgomp testsuite is the last to finish, slowing down the
whole test.
Rainer
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
@ 2022-01-21 20:42 ` belyshev at depni dot sinp.msu.ru
2022-02-08 14:15 ` tschwinge at gcc dot gnu.org
` (30 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: belyshev at depni dot sinp.msu.ru @ 2022-01-21 20:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Serge Belyshev <belyshev at depni dot sinp.msu.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
CC| |belyshev at depni dot sinp.msu.ru
Ever confirmed|0 |1
Last reconfirmed| |2022-01-21
--- Comment #1 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> ---
Confirmed, affects testing via qemu even on modern hardware.
On 32 thread amd64 zen3 box testsuite except libgomp completes in about 150
minutes, libgomp adds 30..40 minutes to that.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
2022-01-21 20:42 ` [Bug libgomp/66005] " belyshev at depni dot sinp.msu.ru
@ 2022-02-08 14:15 ` tschwinge at gcc dot gnu.org
2022-05-29 5:05 ` egallager at gcc dot gnu.org
` (29 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2022-02-08 14:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
First, ACK, and "sorry".
(As has been discussed in the past) we cannot just enable the standard
GCC/DejaGnu parallel testing for the libgomp testsuite, because a lot of the
test cases internally use parallelism, so we'd heavily oversubscribe system
resources.
However, there is one thing that I think we may do, and I'm expecting that to
help a lot: parallelize *all* compilation, while just allowing for *one*
execution test job slot. That will require some GCC DejaGnu test harness
hackery which I've not yet gotten to look into. That is, enable the usual
GCC/DejaGnu parallel testing, but also have some kind of mutex for the
execution test invocation. This has to play nicely with DejaGnu timeout
handling, etc.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
2022-01-21 20:42 ` [Bug libgomp/66005] " belyshev at depni dot sinp.msu.ru
2022-02-08 14:15 ` tschwinge at gcc dot gnu.org
@ 2022-05-29 5:05 ` egallager at gcc dot gnu.org
2023-05-04 15:29 ` tschwinge at gcc dot gnu.org
` (28 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: egallager at gcc dot gnu.org @ 2022-05-29 5:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu.org
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
*** Bug 90084 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (2 preceding siblings ...)
2022-05-29 5:05 ` egallager at gcc dot gnu.org
@ 2023-05-04 15:29 ` tschwinge at gcc dot gnu.org
2023-05-05 9:05 ` tschwinge at gcc dot gnu.org
` (27 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-04 15:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org
Last reconfirmed|2022-01-21 00:00:00 |2023-5-4
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (3 preceding siblings ...)
2023-05-04 15:29 ` tschwinge at gcc dot gnu.org
@ 2023-05-05 9:05 ` tschwinge at gcc dot gnu.org
2023-05-15 10:11 ` cvs-commit at gcc dot gnu.org
` (26 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-05 9:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
-
<https://inbox.sourceware.org/gcc-patches/87h6srb1iq.fsf@euler.schwinge.homeip.net>
"Support parallel testing in libgomp, part I [PR66005]"
-
<https://inbox.sourceware.org/gcc-patches/87ednvb1cc.fsf@euler.schwinge.homeip.net>
"Support parallel testing in libgomp, part II [PR66005]"
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (4 preceding siblings ...)
2023-05-05 9:05 ` tschwinge at gcc dot gnu.org
@ 2023-05-15 10:11 ` cvs-commit at gcc dot gnu.org
2023-05-15 10:12 ` cvs-commit at gcc dot gnu.org
` (25 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-15 10:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:e797db5c744f7b4e110f23a495fca8e6b8aebe83
commit r14-854-ge797db5c744f7b4e110f23a495fca8e6b8aebe83
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu May 7 13:26:57 2015 +0200
Support parallel testing in libgomp, part I [PR66005]
..., while still hard-coding the number of parallel slots to one.
PR testsuite/66005
libgomp/
* testsuite/Makefile.am (PWD_COMMAND): New variable.
(%/site.exp): New target.
(check_p_numbers0, check_p_numbers1, check_p_numbers2)
(check_p_numbers3, check_p_numbers4, check_p_numbers5)
(check_p_numbers6, check_p_numbers, gcc_test_parallel_slots)
(check_p_subdirs)
(check_DEJAGNU_libgomp_targets): New variables.
($(check_DEJAGNU_libgomp_targets)): New target.
($(check_DEJAGNU_libgomp_targets)): New dependency.
(check-DEJAGNU $(check_DEJAGNU_libgomp_targets)): New targets.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp: For parallel testing,
'load_file ../libgomp-test-support.exp'.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug libgomp/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (5 preceding siblings ...)
2023-05-15 10:11 ` cvs-commit at gcc dot gnu.org
@ 2023-05-15 10:12 ` cvs-commit at gcc dot gnu.org
2023-05-15 10:31 ` [Bug testsuite/66005] " tschwinge at gcc dot gnu.org
` (24 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-15 10:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
commit r14-855-g6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue Apr 25 23:53:12 2023 +0200
Support parallel testing in libgomp, part II [PR66005]
..., and enable if 'flock' is available for serializing execution testing.
Regarding the default of 19 parallel slots, this turned out to be a local
minimum for wall time when testing this on:
$ uname -srvi
Linux 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC
2016 x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
32 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
... in two configurations: case (a) standard configuration, no offloading
configured, case (b) offloading for GCN and nvptx configured but no devices
available. For both cases, default plus '-m32' variant.
$ \time make check-target-libgomp
RUNTESTFLAGS="--target_board=unix\{,-m32\}"
Case (a), baseline:
6432.23user 332.38system 47:32.28elapsed 237%CPU (0avgtext+0avgdata
505044maxresident)k
6382.43user 319.21system 47:06.04elapsed 237%CPU (0avgtext+0avgdata
505172maxresident)k
This is what people have been complaining about, rightly so, in
<https://gcc.gnu.org/PR66005> "libgomp make check time is excessive" and
elsewhere.
Case (a), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
3088.49user 267.74system 6:43.82elapsed 831%CPU (0avgtext+0avgdata
505188maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
3308.08user 294.79system 5:56.04elapsed 1011%CPU (0avgtext+0avgdata
505360maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
3539.93user 298.99system 5:27.86elapsed 1170%CPU (0avgtext+0avgdata
505112maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
3697.50user 317.18system 5:14.63elapsed 1275%CPU (0avgtext+0avgdata
505360maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
3765.94user 324.27system 5:13.22elapsed 1305%CPU (0avgtext+0avgdata
505128maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
3684.66user 312.32system 5:15.26elapsed 1267%CPU (0avgtext+0avgdata
505100maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
4040.59user 347.10system 5:29.12elapsed 1333%CPU (0avgtext+0avgdata
505200maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
3973.24user 377.96system 5:24.70elapsed 1340%CPU (0avgtext+0avgdata
505160maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
4004.42user 346.10system 5:16.11elapsed 1376%CPU (0avgtext+0avgdata
505160maxresident)k
Yay!
Case (b), baseline; 2+ h:
7227.58user 700.54system 2:14:33elapsed 98%CPU (0avgtext+0avgdata
994264maxresident)k
Case (b), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
7377.46user 777.52system 16:06.63elapsed 843%CPU (0avgtext+0avgdata
994344maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
8019.18user 721.42system 12:13.56elapsed 1191%CPU (0avgtext+0avgdata
994228maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
8530.11user 716.95system 10:45.92elapsed 1431%CPU (0avgtext+0avgdata
994176maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
8776.79user 645.89system 10:27.20elapsed 1502%CPU (0avgtext+0avgdata
994248maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
9332.37user 641.76system 10:15.09elapsed 1621%CPU (0avgtext+0avgdata
994260maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
9609.54user 789.88system 10:26.94elapsed 1658%CPU (0avgtext+0avgdata
994284maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
10362.40user 911.14system 10:44.47elapsed 1749%CPU (0avgtext+0avgdata
994208maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
11159.44user 850.99system 11:09.25elapsed 1794%CPU (0avgtext+0avgdata
994256maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
11453.50user 939.52system 11:00.38elapsed 1876%CPU (0avgtext+0avgdata
994240maxresident)k
On my Dell Precision 7530 laptop:
$ uname -srvi
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
$ nvidia-smi -L
GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
... in two configurations: case (c) standard configuration, no offloading
configured, case (d) offloading for nvptx configured and device available.
For both cases, only default variant, no '-m32'.
$ \time make check-target-libgomp
Case (c), baseline; roughly half of case (a) (just one variant):
1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
Case (c), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
1143.83user 110.76system 10:20.46elapsed 202%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
1737.08user 143.94system 4:59.48elapsed 628%CPU (0avgtext+0avgdata
505200maxresident)k
1730.31user 143.02system 4:58.75elapsed 627%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
2192.63user 169.34system 4:52.96elapsed 806%CPU (0avgtext+0avgdata
505216maxresident)k
2219.04user 167.67system 4:53.19elapsed 814%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
2463.93user 184.98system 4:48.39elapsed 918%CPU (0avgtext+0avgdata
505200maxresident)k
2455.62user 183.68system 4:47.40elapsed 918%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
2613.18user 199.51system 4:44.06elapsed 990%CPU (0avgtext+0avgdata
505216maxresident)k
Case (d), baseline (compared to case (b): only nvptx offloading
compilation,
but also nvptx offloading execution); ~1 h:
2841.93user 653.68system 1:02:26elapsed 93%CPU (0avgtext+0avgdata
909792maxresident)k
2842.03user 654.39system 1:02:24elapsed 93%CPU (0avgtext+0avgdata
909880maxresident)k
Case (d), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
2856.39user 606.87system 33:58.64elapsed 169%CPU (0avgtext+0avgdata
909948maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
3444.90user 666.86system 18:37.57elapsed 367%CPU (0avgtext+0avgdata
909856maxresident)k
3462.13user 667.13system 18:36.87elapsed 369%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
3929.74user 716.22system 18:02.36elapsed 429%CPU (0avgtext+0avgdata
909832maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
4152.84user 736.16system 17:43.05elapsed 459%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
4209.60user 749.00system 17:35.20elapsed 469%CPU (0avgtext+0avgdata
909840maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
4255.54user 756.78system 17:29.06elapsed 477%CPU (0avgtext+0avgdata
909868maxresident)k
Worth noting is that with nvptx offloading, there is one execution test
case
that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
stalls progress for almost 5 min: quickly other executions test cases queue
up
on the lock for all parallel slots. That's working as expected; just
noting
this as it accordingly does skew the wall time numbers.
PR testsuite/66005
libgomp/
* configure.ac: Look for 'flock'.
* testsuite/Makefile.am (gcc_test_parallel_slots): Enable parallel
testing.
* testsuite/config/default.exp: Don't 'load_lib "standard.exp"'
here...
* testsuite/lib/libgomp.exp: ... but here, instead.
(libgomp_load): Override for parallel testing.
* testsuite/libgomp-site-extra.exp.in (FLOCK): Set.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (6 preceding siblings ...)
2023-05-15 10:12 ` cvs-commit at gcc dot gnu.org
@ 2023-05-15 10:31 ` tschwinge at gcc dot gnu.org
2023-05-15 11:15 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (23 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-15 10:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
Component|libgomp |testsuite
Keywords| |openacc, openmp
--- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Resolved for GCC 14. Not planning on backporting to release branches (but
could, if desired).
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (7 preceding siblings ...)
2023-05-15 10:31 ` [Bug testsuite/66005] " tschwinge at gcc dot gnu.org
@ 2023-05-15 11:15 ` ro at CeBiTec dot Uni-Bielefeld.DE
2023-05-15 11:38 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2023-05-15 11:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> Resolved for GCC 14. Not planning on backporting to release branches (but
> could, if desired).
Unfortunately not: flock is completely unportable. It's not in
POSIX.1/XPG7, and none of Solaris, macOS, or AIX have it.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (8 preceding siblings ...)
2023-05-15 11:15 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2023-05-15 11:38 ` jakub at gcc dot gnu.org
2023-05-15 14:22 ` tschwinge at gcc dot gnu.org
` (21 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-15 11:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to
determine which make check invocation should be given a particular batch of
tests (in an initially empty directory), could you use that instead?
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (9 preceding siblings ...)
2023-05-15 11:38 ` jakub at gcc dot gnu.org
@ 2023-05-15 14:22 ` tschwinge at gcc dot gnu.org
2023-05-15 18:35 ` tschwinge at gcc dot gnu.org
` (20 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-15 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|RESOLVED |REOPENED
--- Comment #10 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
> > --- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> > Resolved for GCC 14. Not planning on backporting to release branches (but
> > could, if desired).
>
> Unfortunately not: flock is completely unportable. It's not in
> POSIX.1/XPG7, and none of Solaris, macOS, or AIX have it.
OK, indeed my approach depends on 'flock'. Otherwise, we still serialize
'check-target-libgomp', as before.
(In reply to Jakub Jelinek from comment #9)
> r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to
> determine which make check invocation should be given a particular batch of
> tests (in an initially empty directory), could you use that instead?
We'd like something that blocks until the lock is available, and something that
works on file descriptors and unlocks implicitly upon 'close'/process exit (to
avoid stale locks).
Using something like Jakub posted with spinning probably does waste too many
parallel slots here? I'll try to experiment with that, though: at the long
tail at the end of overall parallel testing (that is, when all parallel slots
are otherwise unused), it's still better than no parallelism at all?
Could we easily build a portable 'flock'-like using 'fcntl' locking primitives?
(I've not yet looked.)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (10 preceding siblings ...)
2023-05-15 14:22 ` tschwinge at gcc dot gnu.org
@ 2023-05-15 18:35 ` tschwinge at gcc dot gnu.org
2023-05-15 20:06 ` egallager at gcc dot gnu.org
` (19 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-15 18:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #11 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to myself from comment #10)
> Could we easily build a portable 'flock'-like using 'fcntl' locking
> primitives?
(<https://www.perkin.org.uk/posts/solaris-portability-flock.html>, for
example.)
> (I've not yet looked.)
But simpler, is it OK to require Perl (Ick!) for parallelized
'check-target-libgomp'? There's <https://perldoc.perl.org/functions/flock>,
and I've got that implemented as a fallback 'flock'. (It's certainly not,
after two decades or so, my desire to write something in Perl, but I suppose
it's available "almost everywhere" and the fallback 'flock' is simple to
implement.)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (11 preceding siblings ...)
2023-05-15 18:35 ` tschwinge at gcc dot gnu.org
@ 2023-05-15 20:06 ` egallager at gcc dot gnu.org
2023-05-15 20:22 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: egallager at gcc dot gnu.org @ 2023-05-15 20:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #12 from Eric Gallager <egallager at gcc dot gnu.org> ---
Note that there's a gnulib module for flock:
https://www.gnu.org/software/gnulib/manual/html_node/flock.html
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (12 preceding siblings ...)
2023-05-15 20:06 ` egallager at gcc dot gnu.org
@ 2023-05-15 20:22 ` jakub at gcc dot gnu.org
2023-05-15 20:42 ` tschwinge at gcc dot gnu.org
` (17 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-15 20:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And fcntl in tclx. Anyway, I think choosing between flock(1) and some python
file locking would be better than using perl which is only needed in maintainer
mode and not otherwise.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (13 preceding siblings ...)
2023-05-15 20:22 ` jakub at gcc dot gnu.org
@ 2023-05-15 20:42 ` tschwinge at gcc dot gnu.org
2023-05-16 7:46 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (16 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-05-15 20:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #14 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #12)
> Note that there's a gnulib module for flock:
> https://www.gnu.org/software/gnulib/manual/html_node/flock.html
I'd see that one -- but it also says: "the replacement function does not really
work", so I don't think that's useful?
(In reply to Jakub Jelinek from comment #13)
> And fcntl in tclx.
Seen that, too -- but is TclX something that people actually have
available/installed? (Rainer?)
> Anyway, I think choosing between flock(1) and some
> python file locking would be better than using perl which is only needed in
> maintainer mode and not otherwise.
Rainer, would a 'python3' variant work for you?
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (14 preceding siblings ...)
2023-05-15 20:42 ` tschwinge at gcc dot gnu.org
@ 2023-05-16 7:46 ` ro at CeBiTec dot Uni-Bielefeld.DE
2023-05-16 7:57 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2023-05-16 7:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #14 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> (In reply to Eric Gallager from comment #12)
>> Note that there's a gnulib module for flock:
>> https://www.gnu.org/software/gnulib/manual/html_node/flock.html
>
> I'd see that one -- but it also says: "the replacement function does not really
> work", so I don't think that's useful?
Besides, this only provides a replacement for the system call; we'd
still have to implement flock(1) ourselves and I'd rather not see us go
there.
> (In reply to Jakub Jelinek from comment #13)
>> And fcntl in tclx.
>
> Seen that, too -- but is TclX something that people actually have
> available/installed? (Rainer?)
It's not available in packaged form on any of the targets I mentioned
(Solaris, macOS, AIX). Besides, adding something like this feels quite
heavy-handed to me.
>> Anyway, I think choosing between flock(1) and some
>> python file locking would be better than using perl which is only needed in
>> maintainer mode and not otherwise.
>
> Rainer, would a 'python3' variant work for you?
Not really: python3 isn't available on older macOS systems, and again:
adding a python requirement (even for python2 in such a limited case)
seems to go overboard to me.
While I personally don't have a problem with requiring perl (it's needed
to support shared library versioning on Solaris), the same argument
applies.
My strong preference would be to use Tcl core means only, thus adding no
additional requirement. I found a couple of suggestions on how to do
this:
https://wiki.tcl-lang.org/page/How+do+I+manage+lock+files+in+a+cross+platform+manner+in+Tcl
https://wiki.tcl-lang.org/page/Serializing+things+via+file+locks
effectively matching Jakub's suggestion.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (15 preceding siblings ...)
2023-05-16 7:46 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2023-05-16 7:57 ` jakub at gcc dot gnu.org
2023-06-02 7:51 ` cvs-commit at gcc dot gnu.org
` (14 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-16 7:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another possibility would be pick up one runtest (e.g. the first one using
O_EXCL which creates some file) and let it perform all executions from that
point on instead of doing the compilations, where the other runtest would feed
what needs to be executed and later deleted say through a pipe. The reading
through pipe would ensure that it is able to wait if there is no immediate work
for it. Of course we have dg-set-env-var which complicates things a little
bit, probably those would need to be transfered to the execution job together
with what program should run, what options should be passed to it, what
LD_LIBRARY_PATH should be used etc. One issue is make sure all the executable
names are unique even at all optimization levels, we can't have target1.exe
created more than once.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (16 preceding siblings ...)
2023-05-16 7:57 ` jakub at gcc dot gnu.org
@ 2023-06-02 7:51 ` cvs-commit at gcc dot gnu.org
2023-06-02 10:07 ` tschwinge at gcc dot gnu.org
` (13 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-02 7:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:04abe1944d30eb18a2060cfcd9695d085f7b4752
commit r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Mon May 15 20:00:07 2023 +0200
Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]
Follow-up to commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
"Support parallel testing in libgomp, part II [PR66005]"
("..., and enable if 'flock' is available for serializing execution
testing"),
where we saw:
> On my Dell Precision 7530 laptop:
>
> $ uname -srvi
> Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
> $ grep '^model name' < /proc/cpuinfo | uniq -c
> 12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
> $ nvidia-smi -L
> GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
>
> ... [...]: case (c) standard configuration, no offloading
> configured, [...]
> $ \time make check-target-libgomp
>
> Case (c), baseline; [...]:
>
> 1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
> 1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
>
> Case (c), parallelized [using 'flock']:
>
> [...]
> -j12 GCC_TEST_PARALLEL_SLOTS=12
> 2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
> 2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
Quite the same when instead of 'flock' using this fallback Perl 'flock':
2565.23user 194.35system 4:46.77elapsed 962%CPU (0avgtext+0avgdata
505216maxresident)k
2549.38user 200.20system 4:46.08elapsed 961%CPU (0avgtext+0avgdata
505216maxresident)k
PR testsuite/66005
gcc/
* doc/install.texi: Document (optional) Perl usage for parallel
testing of libgomp.
libgomp/
* testsuite/lib/libgomp.exp: 'flock' through stdout.
* testsuite/flock: New.
* configure.ac (FLOCK): Point to that if no 'flock' available, but
'perl' is.
* configure: Regenerate.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (17 preceding siblings ...)
2023-06-02 7:51 ` cvs-commit at gcc dot gnu.org
@ 2023-06-02 10:07 ` tschwinge at gcc dot gnu.org
2023-06-02 10:16 ` iains at gcc dot gnu.org
` (12 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-06-02 10:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #18 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Iain Sandoe from
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951#c4>)
> I am also somewhat puzzled by what conditions I need to take advantage of
> the parallel running?
> Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK
> both at runtime and during config
(That's not actually relevant for libgomp parallel testing.)
> but it seems to be determined to run a single process.
That's the fail-safe default if there's no 'flock' executable available --
which I suspect is the case on your Darwin systems? My recent commit
r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel testing in
libgomp: fallback Perl 'flock' [PR66005]" should've addressed that case (if you
have Perl).
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (18 preceding siblings ...)
2023-06-02 10:07 ` tschwinge at gcc dot gnu.org
@ 2023-06-02 10:16 ` iains at gcc dot gnu.org
2023-06-05 14:52 ` tschwinge at gcc dot gnu.org
` (11 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: iains at gcc dot gnu.org @ 2023-06-02 10:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iains at gcc dot gnu.org
--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #18)
> (In reply to Iain Sandoe from
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951#c4>)
> > I am also somewhat puzzled by what conditions I need to take advantage of
> > the parallel running?
> > Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK
> > both at runtime and during config
>
> (That's not actually relevant for libgomp parallel testing.)
>
> > but it seems to be determined to run a single process.
>
> That's the fail-safe default if there's no 'flock' executable available --
> which I suspect is the case on your Darwin systems? My recent commit
> r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel testing
> in libgomp: fallback Perl 'flock' [PR66005]" should've addressed that case
> (if you have Perl).
thanks. yes flock used to exist on Darwin but was removed some time ago (like
10+ years) so a replacement is needed - and Perl is available so let's see.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (19 preceding siblings ...)
2023-06-02 10:16 ` iains at gcc dot gnu.org
@ 2023-06-05 14:52 ` tschwinge at gcc dot gnu.org
2023-06-23 12:51 ` tschwinge at gcc dot gnu.org
` (10 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-06-05 14:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #20 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #19)
> (In reply to Thomas Schwinge from comment #18)
> > r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]"
>
> [...] Perl is available so let's see.
Thanks for your confirmation in GCC IRC, 2023-06-02:
<iains> tschwinge: 94mins => 15 (wallclock), so the Perl addition is also
working
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (20 preceding siblings ...)
2023-06-05 14:52 ` tschwinge at gcc dot gnu.org
@ 2023-06-23 12:51 ` tschwinge at gcc dot gnu.org
2023-06-23 13:42 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-06-23 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #21 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Jakub, given that 'libgomp is usually the “long tail” of [...] testing' (GCC
IRC, 2023-06-05), Iain has asked that I backport to release branches the
changes implemented here:
- commit r14-854-ge797db5c744f7b4e110f23a495fca8e6b8aebe83 "Support parallel
testing in libgomp, part I [PR66005]"
- commit r14-855-g6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba "Support parallel
testing in libgomp, part II [PR66005]"
- commit r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel
testing in libgomp: fallback Perl 'flock' [PR66005]"
(I haven't looked yet in detail, but there shouldn't be any non-trivial
prerequisite commits, if any at all.)
I've not had any reports about breakage or regressions, so that does seem safe
to me -- any objections?
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (21 preceding siblings ...)
2023-06-23 12:51 ` tschwinge at gcc dot gnu.org
@ 2023-06-23 13:42 ` jakub at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-06-23 13:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, but please do it sooner than later, so there is enough time before 13.2rc
to note potential issues on the branch.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (22 preceding siblings ...)
2023-06-23 13:42 ` jakub at gcc dot gnu.org
@ 2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:2aa6135efb2d5fce93578592d91f8ce19a1b983b
commit r13-7493-g2aa6135efb2d5fce93578592d91f8ce19a1b983b
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu May 7 13:26:57 2015 +0200
Support parallel testing in libgomp, part I [PR66005]
..., while still hard-coding the number of parallel slots to one.
PR testsuite/66005
libgomp/
* testsuite/Makefile.am (PWD_COMMAND): New variable.
(%/site.exp): New target.
(check_p_numbers0, check_p_numbers1, check_p_numbers2)
(check_p_numbers3, check_p_numbers4, check_p_numbers5)
(check_p_numbers6, check_p_numbers, gcc_test_parallel_slots)
(check_p_subdirs)
(check_DEJAGNU_libgomp_targets): New variables.
($(check_DEJAGNU_libgomp_targets)): New target.
($(check_DEJAGNU_libgomp_targets)): New dependency.
(check-DEJAGNU $(check_DEJAGNU_libgomp_targets)): New targets.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp: For parallel testing,
'load_file ../libgomp-test-support.exp'.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit e797db5c744f7b4e110f23a495fca8e6b8aebe83)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (23 preceding siblings ...)
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:3840d5ccf750b6a059258be7faa4a3fce85a6fa6
commit r13-7494-g3840d5ccf750b6a059258be7faa4a3fce85a6fa6
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue Apr 25 23:53:12 2023 +0200
Support parallel testing in libgomp, part II [PR66005]
..., and enable if 'flock' is available for serializing execution testing.
Regarding the default of 19 parallel slots, this turned out to be a local
minimum for wall time when testing this on:
$ uname -srvi
Linux 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC
2016 x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
32 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
... in two configurations: case (a) standard configuration, no offloading
configured, case (b) offloading for GCN and nvptx configured but no devices
available. For both cases, default plus '-m32' variant.
$ \time make check-target-libgomp
RUNTESTFLAGS="--target_board=unix\{,-m32\}"
Case (a), baseline:
6432.23user 332.38system 47:32.28elapsed 237%CPU (0avgtext+0avgdata
505044maxresident)k
6382.43user 319.21system 47:06.04elapsed 237%CPU (0avgtext+0avgdata
505172maxresident)k
This is what people have been complaining about, rightly so, in
<https://gcc.gnu.org/PR66005> "libgomp make check time is excessive" and
elsewhere.
Case (a), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
3088.49user 267.74system 6:43.82elapsed 831%CPU (0avgtext+0avgdata
505188maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
3308.08user 294.79system 5:56.04elapsed 1011%CPU (0avgtext+0avgdata
505360maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
3539.93user 298.99system 5:27.86elapsed 1170%CPU (0avgtext+0avgdata
505112maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
3697.50user 317.18system 5:14.63elapsed 1275%CPU (0avgtext+0avgdata
505360maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
3765.94user 324.27system 5:13.22elapsed 1305%CPU (0avgtext+0avgdata
505128maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
3684.66user 312.32system 5:15.26elapsed 1267%CPU (0avgtext+0avgdata
505100maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
4040.59user 347.10system 5:29.12elapsed 1333%CPU (0avgtext+0avgdata
505200maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
3973.24user 377.96system 5:24.70elapsed 1340%CPU (0avgtext+0avgdata
505160maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
4004.42user 346.10system 5:16.11elapsed 1376%CPU (0avgtext+0avgdata
505160maxresident)k
Yay!
Case (b), baseline; 2+ h:
7227.58user 700.54system 2:14:33elapsed 98%CPU (0avgtext+0avgdata
994264maxresident)k
Case (b), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
7377.46user 777.52system 16:06.63elapsed 843%CPU (0avgtext+0avgdata
994344maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
8019.18user 721.42system 12:13.56elapsed 1191%CPU (0avgtext+0avgdata
994228maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
8530.11user 716.95system 10:45.92elapsed 1431%CPU (0avgtext+0avgdata
994176maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
8776.79user 645.89system 10:27.20elapsed 1502%CPU (0avgtext+0avgdata
994248maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
9332.37user 641.76system 10:15.09elapsed 1621%CPU (0avgtext+0avgdata
994260maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
9609.54user 789.88system 10:26.94elapsed 1658%CPU (0avgtext+0avgdata
994284maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
10362.40user 911.14system 10:44.47elapsed 1749%CPU (0avgtext+0avgdata
994208maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
11159.44user 850.99system 11:09.25elapsed 1794%CPU (0avgtext+0avgdata
994256maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
11453.50user 939.52system 11:00.38elapsed 1876%CPU (0avgtext+0avgdata
994240maxresident)k
On my Dell Precision 7530 laptop:
$ uname -srvi
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
$ nvidia-smi -L
GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
... in two configurations: case (c) standard configuration, no offloading
configured, case (d) offloading for nvptx configured and device available.
For both cases, only default variant, no '-m32'.
$ \time make check-target-libgomp
Case (c), baseline; roughly half of case (a) (just one variant):
1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
Case (c), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
1143.83user 110.76system 10:20.46elapsed 202%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
1737.08user 143.94system 4:59.48elapsed 628%CPU (0avgtext+0avgdata
505200maxresident)k
1730.31user 143.02system 4:58.75elapsed 627%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
2192.63user 169.34system 4:52.96elapsed 806%CPU (0avgtext+0avgdata
505216maxresident)k
2219.04user 167.67system 4:53.19elapsed 814%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
2463.93user 184.98system 4:48.39elapsed 918%CPU (0avgtext+0avgdata
505200maxresident)k
2455.62user 183.68system 4:47.40elapsed 918%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
2613.18user 199.51system 4:44.06elapsed 990%CPU (0avgtext+0avgdata
505216maxresident)k
Case (d), baseline (compared to case (b): only nvptx offloading
compilation,
but also nvptx offloading execution); ~1 h:
2841.93user 653.68system 1:02:26elapsed 93%CPU (0avgtext+0avgdata
909792maxresident)k
2842.03user 654.39system 1:02:24elapsed 93%CPU (0avgtext+0avgdata
909880maxresident)k
Case (d), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
2856.39user 606.87system 33:58.64elapsed 169%CPU (0avgtext+0avgdata
909948maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
3444.90user 666.86system 18:37.57elapsed 367%CPU (0avgtext+0avgdata
909856maxresident)k
3462.13user 667.13system 18:36.87elapsed 369%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
3929.74user 716.22system 18:02.36elapsed 429%CPU (0avgtext+0avgdata
909832maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
4152.84user 736.16system 17:43.05elapsed 459%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
4209.60user 749.00system 17:35.20elapsed 469%CPU (0avgtext+0avgdata
909840maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
4255.54user 756.78system 17:29.06elapsed 477%CPU (0avgtext+0avgdata
909868maxresident)k
Worth noting is that with nvptx offloading, there is one execution test
case
that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
stalls progress for almost 5 min: quickly other executions test cases queue
up
on the lock for all parallel slots. That's working as expected; just
noting
this as it accordingly does skew the wall time numbers.
PR testsuite/66005
libgomp/
* configure.ac: Look for 'flock'.
* testsuite/Makefile.am (gcc_test_parallel_slots): Enable parallel
testing.
* testsuite/config/default.exp: Don't 'load_lib "standard.exp"'
here...
* testsuite/lib/libgomp.exp: ... but here, instead.
(libgomp_load): Override for parallel testing.
* testsuite/libgomp-site-extra.exp.in (FLOCK): Set.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
(cherry picked from commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (24 preceding siblings ...)
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:40 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:09124b7ed7709721e86556b4083ef40925d7489b
commit r13-7495-g09124b7ed7709721e86556b4083ef40925d7489b
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Mon May 15 20:00:07 2023 +0200
Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]
Follow-up to commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
"Support parallel testing in libgomp, part II [PR66005]"
("..., and enable if 'flock' is available for serializing execution
testing"),
where we saw:
> On my Dell Precision 7530 laptop:
>
> $ uname -srvi
> Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
> $ grep '^model name' < /proc/cpuinfo | uniq -c
> 12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
> $ nvidia-smi -L
> GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
>
> ... [...]: case (c) standard configuration, no offloading
> configured, [...]
> $ \time make check-target-libgomp
>
> Case (c), baseline; [...]:
>
> 1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
> 1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
>
> Case (c), parallelized [using 'flock']:
>
> [...]
> -j12 GCC_TEST_PARALLEL_SLOTS=12
> 2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
> 2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
Quite the same when instead of 'flock' using this fallback Perl 'flock':
2565.23user 194.35system 4:46.77elapsed 962%CPU (0avgtext+0avgdata
505216maxresident)k
2549.38user 200.20system 4:46.08elapsed 961%CPU (0avgtext+0avgdata
505216maxresident)k
PR testsuite/66005
gcc/
* doc/install.texi: Document (optional) Perl usage for parallel
testing of libgomp.
libgomp/
* testsuite/lib/libgomp.exp: 'flock' through stdout.
* testsuite/flock: New.
* configure.ac (FLOCK): Point to that if no 'flock' available, but
'perl' is.
* configure: Regenerate.
(cherry picked from commit 04abe1944d30eb18a2060cfcd9695d085f7b4752)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (25 preceding siblings ...)
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:40 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:66df913899d32e7726f986afb61c5c5615eb2a36
commit r12-9737-g66df913899d32e7726f986afb61c5c5615eb2a36
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu May 7 13:26:57 2015 +0200
Support parallel testing in libgomp, part I [PR66005]
..., while still hard-coding the number of parallel slots to one.
PR testsuite/66005
libgomp/
* testsuite/Makefile.am (PWD_COMMAND): New variable.
(%/site.exp): New target.
(check_p_numbers0, check_p_numbers1, check_p_numbers2)
(check_p_numbers3, check_p_numbers4, check_p_numbers5)
(check_p_numbers6, check_p_numbers, gcc_test_parallel_slots)
(check_p_subdirs)
(check_DEJAGNU_libgomp_targets): New variables.
($(check_DEJAGNU_libgomp_targets)): New target.
($(check_DEJAGNU_libgomp_targets)): New dependency.
(check-DEJAGNU $(check_DEJAGNU_libgomp_targets)): New targets.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp: For parallel testing,
'load_file ../libgomp-test-support.exp'.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit e797db5c744f7b4e110f23a495fca8e6b8aebe83)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (26 preceding siblings ...)
2023-06-28 11:40 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:5c6515076f2ba55a31149085d3826e975c114fe5
commit r12-9738-g5c6515076f2ba55a31149085d3826e975c114fe5
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue Apr 25 23:53:12 2023 +0200
Support parallel testing in libgomp, part II [PR66005]
..., and enable if 'flock' is available for serializing execution testing.
Regarding the default of 19 parallel slots, this turned out to be a local
minimum for wall time when testing this on:
$ uname -srvi
Linux 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC
2016 x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
32 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
... in two configurations: case (a) standard configuration, no offloading
configured, case (b) offloading for GCN and nvptx configured but no devices
available. For both cases, default plus '-m32' variant.
$ \time make check-target-libgomp
RUNTESTFLAGS="--target_board=unix\{,-m32\}"
Case (a), baseline:
6432.23user 332.38system 47:32.28elapsed 237%CPU (0avgtext+0avgdata
505044maxresident)k
6382.43user 319.21system 47:06.04elapsed 237%CPU (0avgtext+0avgdata
505172maxresident)k
This is what people have been complaining about, rightly so, in
<https://gcc.gnu.org/PR66005> "libgomp make check time is excessive" and
elsewhere.
Case (a), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
3088.49user 267.74system 6:43.82elapsed 831%CPU (0avgtext+0avgdata
505188maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
3308.08user 294.79system 5:56.04elapsed 1011%CPU (0avgtext+0avgdata
505360maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
3539.93user 298.99system 5:27.86elapsed 1170%CPU (0avgtext+0avgdata
505112maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
3697.50user 317.18system 5:14.63elapsed 1275%CPU (0avgtext+0avgdata
505360maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
3765.94user 324.27system 5:13.22elapsed 1305%CPU (0avgtext+0avgdata
505128maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
3684.66user 312.32system 5:15.26elapsed 1267%CPU (0avgtext+0avgdata
505100maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
4040.59user 347.10system 5:29.12elapsed 1333%CPU (0avgtext+0avgdata
505200maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
3973.24user 377.96system 5:24.70elapsed 1340%CPU (0avgtext+0avgdata
505160maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
4004.42user 346.10system 5:16.11elapsed 1376%CPU (0avgtext+0avgdata
505160maxresident)k
Yay!
Case (b), baseline; 2+ h:
7227.58user 700.54system 2:14:33elapsed 98%CPU (0avgtext+0avgdata
994264maxresident)k
Case (b), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
7377.46user 777.52system 16:06.63elapsed 843%CPU (0avgtext+0avgdata
994344maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
8019.18user 721.42system 12:13.56elapsed 1191%CPU (0avgtext+0avgdata
994228maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
8530.11user 716.95system 10:45.92elapsed 1431%CPU (0avgtext+0avgdata
994176maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
8776.79user 645.89system 10:27.20elapsed 1502%CPU (0avgtext+0avgdata
994248maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
9332.37user 641.76system 10:15.09elapsed 1621%CPU (0avgtext+0avgdata
994260maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
9609.54user 789.88system 10:26.94elapsed 1658%CPU (0avgtext+0avgdata
994284maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
10362.40user 911.14system 10:44.47elapsed 1749%CPU (0avgtext+0avgdata
994208maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
11159.44user 850.99system 11:09.25elapsed 1794%CPU (0avgtext+0avgdata
994256maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
11453.50user 939.52system 11:00.38elapsed 1876%CPU (0avgtext+0avgdata
994240maxresident)k
On my Dell Precision 7530 laptop:
$ uname -srvi
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
$ nvidia-smi -L
GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
... in two configurations: case (c) standard configuration, no offloading
configured, case (d) offloading for nvptx configured and device available.
For both cases, only default variant, no '-m32'.
$ \time make check-target-libgomp
Case (c), baseline; roughly half of case (a) (just one variant):
1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
Case (c), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
1143.83user 110.76system 10:20.46elapsed 202%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
1737.08user 143.94system 4:59.48elapsed 628%CPU (0avgtext+0avgdata
505200maxresident)k
1730.31user 143.02system 4:58.75elapsed 627%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
2192.63user 169.34system 4:52.96elapsed 806%CPU (0avgtext+0avgdata
505216maxresident)k
2219.04user 167.67system 4:53.19elapsed 814%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
2463.93user 184.98system 4:48.39elapsed 918%CPU (0avgtext+0avgdata
505200maxresident)k
2455.62user 183.68system 4:47.40elapsed 918%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
2613.18user 199.51system 4:44.06elapsed 990%CPU (0avgtext+0avgdata
505216maxresident)k
Case (d), baseline (compared to case (b): only nvptx offloading
compilation,
but also nvptx offloading execution); ~1 h:
2841.93user 653.68system 1:02:26elapsed 93%CPU (0avgtext+0avgdata
909792maxresident)k
2842.03user 654.39system 1:02:24elapsed 93%CPU (0avgtext+0avgdata
909880maxresident)k
Case (d), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
2856.39user 606.87system 33:58.64elapsed 169%CPU (0avgtext+0avgdata
909948maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
3444.90user 666.86system 18:37.57elapsed 367%CPU (0avgtext+0avgdata
909856maxresident)k
3462.13user 667.13system 18:36.87elapsed 369%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
3929.74user 716.22system 18:02.36elapsed 429%CPU (0avgtext+0avgdata
909832maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
4152.84user 736.16system 17:43.05elapsed 459%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
4209.60user 749.00system 17:35.20elapsed 469%CPU (0avgtext+0avgdata
909840maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
4255.54user 756.78system 17:29.06elapsed 477%CPU (0avgtext+0avgdata
909868maxresident)k
Worth noting is that with nvptx offloading, there is one execution test
case
that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
stalls progress for almost 5 min: quickly other executions test cases queue
up
on the lock for all parallel slots. That's working as expected; just
noting
this as it accordingly does skew the wall time numbers.
PR testsuite/66005
libgomp/
* configure.ac: Look for 'flock'.
* testsuite/Makefile.am (gcc_test_parallel_slots): Enable parallel
testing.
* testsuite/config/default.exp: Don't 'load_lib "standard.exp"'
here...
* testsuite/lib/libgomp.exp: ... but here, instead.
(libgomp_load): Override for parallel testing.
* testsuite/libgomp-site-extra.exp.in (FLOCK): Set.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
(cherry picked from commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (27 preceding siblings ...)
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #28 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:b4561b782427cdfe0fac1a869e79a49187817ffe
commit r12-9739-gb4561b782427cdfe0fac1a869e79a49187817ffe
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Mon May 15 20:00:07 2023 +0200
Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]
Follow-up to commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
"Support parallel testing in libgomp, part II [PR66005]"
("..., and enable if 'flock' is available for serializing execution
testing"),
where we saw:
> On my Dell Precision 7530 laptop:
>
> $ uname -srvi
> Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
> $ grep '^model name' < /proc/cpuinfo | uniq -c
> 12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
> $ nvidia-smi -L
> GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
>
> ... [...]: case (c) standard configuration, no offloading
> configured, [...]
> $ \time make check-target-libgomp
>
> Case (c), baseline; [...]:
>
> 1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
> 1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
>
> Case (c), parallelized [using 'flock']:
>
> [...]
> -j12 GCC_TEST_PARALLEL_SLOTS=12
> 2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
> 2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
Quite the same when instead of 'flock' using this fallback Perl 'flock':
2565.23user 194.35system 4:46.77elapsed 962%CPU (0avgtext+0avgdata
505216maxresident)k
2549.38user 200.20system 4:46.08elapsed 961%CPU (0avgtext+0avgdata
505216maxresident)k
PR testsuite/66005
gcc/
* doc/install.texi: Document (optional) Perl usage for parallel
testing of libgomp.
libgomp/
* testsuite/lib/libgomp.exp: 'flock' through stdout.
* testsuite/flock: New.
* configure.ac (FLOCK): Point to that if no 'flock' available, but
'perl' is.
* configure: Regenerate.
(cherry picked from commit 04abe1944d30eb18a2060cfcd9695d085f7b4752)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (28 preceding siblings ...)
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:e1bd4f5434d7989d723188e9f2b524ce234bc44d
commit r11-10879-ge1bd4f5434d7989d723188e9f2b524ce234bc44d
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu May 7 13:26:57 2015 +0200
Support parallel testing in libgomp, part I [PR66005]
..., while still hard-coding the number of parallel slots to one.
PR testsuite/66005
libgomp/
* testsuite/Makefile.am (PWD_COMMAND): New variable.
(%/site.exp): New target.
(check_p_numbers0, check_p_numbers1, check_p_numbers2)
(check_p_numbers3, check_p_numbers4, check_p_numbers5)
(check_p_numbers6, check_p_numbers, gcc_test_parallel_slots)
(check_p_subdirs)
(check_DEJAGNU_libgomp_targets): New variables.
($(check_DEJAGNU_libgomp_targets)): New target.
($(check_DEJAGNU_libgomp_targets)): New dependency.
(check-DEJAGNU $(check_DEJAGNU_libgomp_targets)): New targets.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp: For parallel testing,
'load_file ../libgomp-test-support.exp'.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit e797db5c744f7b4e110f23a495fca8e6b8aebe83)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (29 preceding siblings ...)
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:4506b349cf527834239554a03e43ae45237b315c
commit r11-10880-g4506b349cf527834239554a03e43ae45237b315c
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue Apr 25 23:53:12 2023 +0200
Support parallel testing in libgomp, part II [PR66005]
..., and enable if 'flock' is available for serializing execution testing.
Regarding the default of 19 parallel slots, this turned out to be a local
minimum for wall time when testing this on:
$ uname -srvi
Linux 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC
2016 x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
32 model name : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
... in two configurations: case (a) standard configuration, no offloading
configured, case (b) offloading for GCN and nvptx configured but no devices
available. For both cases, default plus '-m32' variant.
$ \time make check-target-libgomp
RUNTESTFLAGS="--target_board=unix\{,-m32\}"
Case (a), baseline:
6432.23user 332.38system 47:32.28elapsed 237%CPU (0avgtext+0avgdata
505044maxresident)k
6382.43user 319.21system 47:06.04elapsed 237%CPU (0avgtext+0avgdata
505172maxresident)k
This is what people have been complaining about, rightly so, in
<https://gcc.gnu.org/PR66005> "libgomp make check time is excessive" and
elsewhere.
Case (a), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
3088.49user 267.74system 6:43.82elapsed 831%CPU (0avgtext+0avgdata
505188maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
3308.08user 294.79system 5:56.04elapsed 1011%CPU (0avgtext+0avgdata
505360maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
3539.93user 298.99system 5:27.86elapsed 1170%CPU (0avgtext+0avgdata
505112maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
3697.50user 317.18system 5:14.63elapsed 1275%CPU (0avgtext+0avgdata
505360maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
3765.94user 324.27system 5:13.22elapsed 1305%CPU (0avgtext+0avgdata
505128maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
3684.66user 312.32system 5:15.26elapsed 1267%CPU (0avgtext+0avgdata
505100maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
4040.59user 347.10system 5:29.12elapsed 1333%CPU (0avgtext+0avgdata
505200maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
3973.24user 377.96system 5:24.70elapsed 1340%CPU (0avgtext+0avgdata
505160maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
4004.42user 346.10system 5:16.11elapsed 1376%CPU (0avgtext+0avgdata
505160maxresident)k
Yay!
Case (b), baseline; 2+ h:
7227.58user 700.54system 2:14:33elapsed 98%CPU (0avgtext+0avgdata
994264maxresident)k
Case (b), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=10
7377.46user 777.52system 16:06.63elapsed 843%CPU (0avgtext+0avgdata
994344maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
8019.18user 721.42system 12:13.56elapsed 1191%CPU (0avgtext+0avgdata
994228maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
8530.11user 716.95system 10:45.92elapsed 1431%CPU (0avgtext+0avgdata
994176maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
8776.79user 645.89system 10:27.20elapsed 1502%CPU (0avgtext+0avgdata
994248maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
9332.37user 641.76system 10:15.09elapsed 1621%CPU (0avgtext+0avgdata
994260maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
9609.54user 789.88system 10:26.94elapsed 1658%CPU (0avgtext+0avgdata
994284maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
10362.40user 911.14system 10:44.47elapsed 1749%CPU (0avgtext+0avgdata
994208maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
11159.44user 850.99system 11:09.25elapsed 1794%CPU (0avgtext+0avgdata
994256maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
11453.50user 939.52system 11:00.38elapsed 1876%CPU (0avgtext+0avgdata
994240maxresident)k
On my Dell Precision 7530 laptop:
$ uname -srvi
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
$ nvidia-smi -L
GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
... in two configurations: case (c) standard configuration, no offloading
configured, case (d) offloading for nvptx configured and device available.
For both cases, only default variant, no '-m32'.
$ \time make check-target-libgomp
Case (c), baseline; roughly half of case (a) (just one variant):
1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
Case (c), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
1143.83user 110.76system 10:20.46elapsed 202%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
1737.08user 143.94system 4:59.48elapsed 628%CPU (0avgtext+0avgdata
505200maxresident)k
1730.31user 143.02system 4:58.75elapsed 627%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
2192.63user 169.34system 4:52.96elapsed 806%CPU (0avgtext+0avgdata
505216maxresident)k
2219.04user 167.67system 4:53.19elapsed 814%CPU (0avgtext+0avgdata
505152maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
2463.93user 184.98system 4:48.39elapsed 918%CPU (0avgtext+0avgdata
505200maxresident)k
2455.62user 183.68system 4:47.40elapsed 918%CPU (0avgtext+0avgdata
505216maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
2613.18user 199.51system 4:44.06elapsed 990%CPU (0avgtext+0avgdata
505216maxresident)k
Case (d), baseline (compared to case (b): only nvptx offloading
compilation,
but also nvptx offloading execution); ~1 h:
2841.93user 653.68system 1:02:26elapsed 93%CPU (0avgtext+0avgdata
909792maxresident)k
2842.03user 654.39system 1:02:24elapsed 93%CPU (0avgtext+0avgdata
909880maxresident)k
Case (d), parallelized:
-j12 GCC_TEST_PARALLEL_SLOTS=2
2856.39user 606.87system 33:58.64elapsed 169%CPU (0avgtext+0avgdata
909948maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=6
3444.90user 666.86system 18:37.57elapsed 367%CPU (0avgtext+0avgdata
909856maxresident)k
3462.13user 667.13system 18:36.87elapsed 369%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=8
3929.74user 716.22system 18:02.36elapsed 429%CPU (0avgtext+0avgdata
909832maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=10
4152.84user 736.16system 17:43.05elapsed 459%CPU (0avgtext+0avgdata
909872maxresident)k
-j12 GCC_TEST_PARALLEL_SLOTS=12
4209.60user 749.00system 17:35.20elapsed 469%CPU (0avgtext+0avgdata
909840maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20 [oversubscribe]
4255.54user 756.78system 17:29.06elapsed 477%CPU (0avgtext+0avgdata
909868maxresident)k
Worth noting is that with nvptx offloading, there is one execution test
case
that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
stalls progress for almost 5 min: quickly other executions test cases queue
up
on the lock for all parallel slots. That's working as expected; just
noting
this as it accordingly does skew the wall time numbers.
PR testsuite/66005
libgomp/
* configure.ac: Look for 'flock'.
* testsuite/Makefile.am (gcc_test_parallel_slots): Enable parallel
testing.
* testsuite/config/default.exp: Don't 'load_lib "standard.exp"'
here...
* testsuite/lib/libgomp.exp: ... but here, instead.
(libgomp_load): Override for parallel testing.
* testsuite/libgomp-site-extra.exp.in (FLOCK): Set.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
(cherry picked from commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug testsuite/66005] libgomp make check time is excessive
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
` (30 preceding siblings ...)
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
@ 2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-28 11:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #31 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:
https://gcc.gnu.org/g:91955e374e07dc8ee9111eeb49c137c5582ed674
commit r11-10881-g91955e374e07dc8ee9111eeb49c137c5582ed674
Author: Thomas Schwinge <thomas@codesourcery.com>
Date: Mon May 15 20:00:07 2023 +0200
Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]
Follow-up to commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
"Support parallel testing in libgomp, part II [PR66005]"
("..., and enable if 'flock' is available for serializing execution
testing"),
where we saw:
> On my Dell Precision 7530 laptop:
>
> $ uname -srvi
> Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
> $ grep '^model name' < /proc/cpuinfo | uniq -c
> 12 model name : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
> $ nvidia-smi -L
> GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
>
> ... [...]: case (c) standard configuration, no offloading
> configured, [...]
> $ \time make check-target-libgomp
>
> Case (c), baseline; [...]:
>
> 1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
> 1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
>
> Case (c), parallelized [using 'flock']:
>
> [...]
> -j12 GCC_TEST_PARALLEL_SLOTS=12
> 2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
> 2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k
Quite the same when instead of 'flock' using this fallback Perl 'flock':
2565.23user 194.35system 4:46.77elapsed 962%CPU (0avgtext+0avgdata
505216maxresident)k
2549.38user 200.20system 4:46.08elapsed 961%CPU (0avgtext+0avgdata
505216maxresident)k
PR testsuite/66005
gcc/
* doc/install.texi: Document (optional) Perl usage for parallel
testing of libgomp.
libgomp/
* testsuite/lib/libgomp.exp: 'flock' through stdout.
* testsuite/flock: New.
* configure.ac (FLOCK): Point to that if no 'flock' available, but
'perl' is.
* configure: Regenerate.
(cherry picked from commit 04abe1944d30eb18a2060cfcd9695d085f7b4752)
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2023-06-28 11:42 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-04 13:38 [Bug libgomp/66005] New: libgomp make check time is excessive ro at gcc dot gnu.org
2022-01-21 20:42 ` [Bug libgomp/66005] " belyshev at depni dot sinp.msu.ru
2022-02-08 14:15 ` tschwinge at gcc dot gnu.org
2022-05-29 5:05 ` egallager at gcc dot gnu.org
2023-05-04 15:29 ` tschwinge at gcc dot gnu.org
2023-05-05 9:05 ` tschwinge at gcc dot gnu.org
2023-05-15 10:11 ` cvs-commit at gcc dot gnu.org
2023-05-15 10:12 ` cvs-commit at gcc dot gnu.org
2023-05-15 10:31 ` [Bug testsuite/66005] " tschwinge at gcc dot gnu.org
2023-05-15 11:15 ` ro at CeBiTec dot Uni-Bielefeld.DE
2023-05-15 11:38 ` jakub at gcc dot gnu.org
2023-05-15 14:22 ` tschwinge at gcc dot gnu.org
2023-05-15 18:35 ` tschwinge at gcc dot gnu.org
2023-05-15 20:06 ` egallager at gcc dot gnu.org
2023-05-15 20:22 ` jakub at gcc dot gnu.org
2023-05-15 20:42 ` tschwinge at gcc dot gnu.org
2023-05-16 7:46 ` ro at CeBiTec dot Uni-Bielefeld.DE
2023-05-16 7:57 ` jakub at gcc dot gnu.org
2023-06-02 7:51 ` cvs-commit at gcc dot gnu.org
2023-06-02 10:07 ` tschwinge at gcc dot gnu.org
2023-06-02 10:16 ` iains at gcc dot gnu.org
2023-06-05 14:52 ` tschwinge at gcc dot gnu.org
2023-06-23 12:51 ` tschwinge at gcc dot gnu.org
2023-06-23 13:42 ` jakub at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:39 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:40 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:41 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
2023-06-28 11:42 ` cvs-commit at gcc dot gnu.org
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).