From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BDD583858D39; Thu, 25 May 2023 23:12:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDD583858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685056340; bh=jO5Xo8Sue9ZOLPcE1Qa7CKErcDDoxvk6npJLW7lqwlI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GT8U48wNiRlHIKyGILp0Id0CZnjHjg3fm70mbKJfo3wqIREvOfltKrOpvVMmhLlaJ 4SfICnQROUOusClyUPQpCl94HGpkg1l7rsVLWNjVMu9hEJzHsDxi8+SujUKEmMfBZx tNvUhv2j0rqdS7GSCFdPgYivsCOtV791jAo+mNZI= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin. Date: Thu, 25 May 2023 23:12:20 +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: 14.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109951 --- Comment #4 from Iain Sandoe --- (In reply to Thomas Schwinge from comment #3) > Looking at your "test x86_64 multilib on i686" case. The situation is simply mirrored for an x86_64 host with an i686 non-native lib. > First, is my understanding correct, that 'GXX_UNDER_TEST' > 'i686-apple-darwin9/libgomp/testsuite/site.exp' does contain the correct > flags/paths for the default ("native", "i686") multilib, but incorrect for > the other ("non-native", "x86_64") multilib? Yes, this information is in a section included from "libgomp-site-extra.exp= "=20 ## Begin content included from file libgomp-site-extra.exp. Do not modify.= ## set GXX_UNDER_TEST {/scratch/10-5-leo/gcc-master/./gcc/xg++ -B/scratch/10-5-leo/gcc-master/./gcc/ -nostdinc++ -funconfigured-libstdc++-= v3 -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/src -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/src/.libs -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/libstdc++-v3/libsupc++/.l= ibs -B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/bin/ -B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/lib/ -isystem /opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/include -isyst= em /opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include=20= =20 -fchecking=3D1} ^^^ yes this is correct for the native mlib, and wrong arch for the non-nat= ive. ## End content included from file libgomp-site-extra.exp. ## > Conversely, would > 'i686-apple-darwin9/x86_64/libgomp/testsuite/site.exp' contain the correct > flags/paths for the other ("non-native", "x86_64") multilib? (..., but t= hat > latter file is never used, always the former 'site.exp'; similar to my > "Indeed there is some confusion there" comment in > -- > but that one's benign, in contrast to your case). Actually, there is no site.exp in that dir. There is a "libgomp-site-extra.exp" which does contain the correct paths. set GXX_UNDER_TEST {/scratch/10-5-leo/gcc-master/./gcc/xg++ -B/scratch/10-5-leo/gcc-master/./gcc/ -nostdinc++ -funconfigured-libstdc++-= v3 -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/src -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/src/.= libs -L/scratch/10-5-leo/gcc-master/i686-apple-darwin9/x86_64/libstdc++-v3/libsu= pc++/.libs -B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/bin/ -B/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/lib/ -isystem /opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/include -isyst= em /opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include -fchecking=3D1 -m64} ^^^ Yes, this looks correct for testing the non-native x86_64 lib. > Second, do you not have similar confusion in 'GCC_UNDER_TEST' and > 'GFORTRAN_UNDER_TEST' flags/paths? No. the confusion does not arise in either of those cases, since they do not hardwire "-L" paths for the runtime libraries (I guess that they expect tho= se to be added by the consumer - which [I *think*] libgomp would do correctly). Of course, there might be some other subtlety - that has just not yet surfa= ced. > (May help me to attach all the relevant 'site.exp' files.) I will sort that out tomorrow (if needed) - I've pasted in the relevant pie= ces for the GXX_UNDER_TEST above. > Third, see Maciej's Subversion r279708 (Git commit > c8e759b4215ba4b376c9d468aeffe163b3d520f0) "libgomp/test: Fix compilation = for > build sysroot", followed by Git commit > 749bd22ddc50b5112e5ed506ffef7249bf8e6fb3 "libgomp/test: Remove a build > sysroot fix regression" (for libgomp, and similarly other commits for a > number of (but not all?) other GCC target libraries). This is what start= ed > capturing 'CC' for test-time use as 'GCC_UNDER_TEST', and this is what in > recent commit 11f4d483600b5788a3d1cf1527e838e4a7ed1455 "libgomp testsuite: I do not yet understand any of this ^^ ( hopefully, I will not need to :) ) > As appropriate, use the 'gcc', 'g++', 'gfortran' driver [PR91884]" I've t= hen > extended for 'CXX': 'GXX_UNDER_TEST', 'FC': 'GFORTRAN_UNDER_TEST'. I > however don't understand yet the original intent of his change; in my > understanding, and as has been the case before, we'd just get > 'GCC_UNDER_TEST' etc. populated by 'find_gcc' etc. The principle seems reasonable, the issue is that it's currently not telling the truth (i.e. it is _not_ the G**_UNDER_TEST) when the testing is in the non-native multilib, =3D=3D=3D=3D=3D I am also somewhat puzzled by what conditions I need to take advantage of t= he parallel running? Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK bo= th at runtime and during config, but it seems to be determined to run a single process.=