From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CB5BE3857736; Mon, 15 May 2023 14:22:37 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB5BE3857736
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684160557;
	bh=iM2dSG3My3NAziOeuCGnWB3sB/BW/bvIx1q4XPPSqOM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tz45BZ8w8XYjaZjXnao9Iu1XyFlXdkkFOys6OMXg4c6WQj81fDQrxJLdKJDpAotdx
	 Ulq66kGYYrf2Thsa5YSjKQXNDokWQjQFUkAwTqWlMB/FQAuinwhWUHxV07RL4+OiIx
	 YXEgVn2iG6wGpjjGhRqR3m9i7oEcrF6ccb/rZQ1s=
From: "tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/66005] libgomp make check time is excessive
Date: Mon, 15 May 2023 14:22:37 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: openacc, openmp, patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tschwinge at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tschwinge at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: resolution bug_status
Message-ID: <bug-66005-4-V9jv4iOfa8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66005-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66005-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66005

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).
>=20
> 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 slo=
ts
are otherwise unused), it's still better than no parallelism at all?

Could we easily build a portable 'flock'-like using 'fcntl' locking primiti=
ves?
 (I've not yet looked.)=