[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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" 

<snip>
## Begin content included from file libgomp-site-extra.exp.  Do not modify. ##
<snip>
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++/.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 -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include  
-fchecking=1}

^^^ yes this is correct for the native mlib, and wrong arch for the non-native.

## 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 that
> latter file is never used, always the former 'site.exp'; similar to my
> "Indeed there is some confusion there" comment in
> <https://inbox.sourceware.org/87bkivayue.fsf@euler.schwinge.homeip.net> --
> 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/libsupc++/.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 -isystem
/opt/iains/i686-apple-darwin9/gcc-14-0-0p/i686-apple-darwin9/sys-include
-fchecking=1  -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 those
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 surfaced.

> (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 pieces
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 started
> 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 then
> 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,

=====

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, but it seems to be determined to run a single
process.