On Mon, 8 May 2023 12:42:33 +0200
Thomas Schwinge <tho...@codesourcery.com> wrote:
> >> +if [info exists ::env(GCC_RUNTEST_PARALLELIZE_DIR)] {
> >> + load_file ../libgomp-test-support.exp
> >> +} else {
> >> + load_file libgomp-test-support.exp
> >> +}
> >
> > Do we have to re-read those? Otherwise this would be load_lib:
>
> Indeed there is some confusion there; conceptually the content of that
> file has to be expected to vary per libgomp (multilib) build variant.
> On the other hand, given the GCC target libraries testing setup, we're
> running testing always via the default variant's build, so always read
> the default variant's file. I agree that should get un-confused, however
> it's a pre-existing issue that I suggest we tackle independently of this
> mechanical change.
Sure. One thing at a time.
> > Some cosmetic nits.
> > See Jakubs one_to_9999.
>
> Thanks. That got installed while I'd already finished my patch. ;-)
> Note that the new 'one_to_9999' etc. is just the existing
> 'check_p_numbers' etc. renamed and moved, as it now has a second use.
> I'm happy to incorporate that into my changes -- if we agree that it
> should also go into other GCC target libraries' parallel testing code:
> libphobos, libstdc++-v3.
Yes. Streamlining these can be done in follow-ups if the respective
maintainers agree.
> >> >> It is far from trivial though.
> >> >> The point is that most of the OpenMP tests are parallelized with the
> >> >> default OMP_NUM_THREADS, so running the tests in parallel
> >> >> oversubscribes the
> >> >> machine a lot, the higher number of hw threads the more.
[]
> >> > the same time? For example, a new dg-* directive to run them wrapped
> >> > through »flock [libgomp/testsuite/serial.lock] [a.out]« or some such?
> >
> > I think we all agree one that, yes.
>
> Conceptually, yes. However, given that my
> "Support parallel testing in libgomp, part II [PR66005]" changes already
> seem to enable a great amount of parallelism, occupying CPUs almost
> fully, I'm not actually sure now if adding more parallelism via
> tedious-to-maintain new dg-* directives is actually necessary/useful. As
> long as libgomp testing now no longer is at the long tail end of overall
> testing time, I'd rather keep it simple?
If the testsuite runtime is fine with your part II as is then we
should keep it as simple as possible.
> >> > (Will again have the problem that DejaGnu doesn't provide infrastructure
> >> > to communicate environment variables to boards in remote testing.)
> >
> > Are you sure? I'm pretty confident that this worked fine at least at
> > one point in the past for certain targets.
>
> For example, see the comments/references in recent
> <https://inbox.sourceware.org/018bcdeb-b3bb-1859-cd0b-a8a92e26d...@codesourcery.com>.
oh, i think i had an rsh2 remote that uploaded $program.env and the rsh
itself was something like
$RSH $rsh_useropts $hostname sh -c 'test -r $program.env && .
$program.env \\; $program $pargs \\; echo ...
but that was ages ago and was properly implemented in the meantime, one
would hope? Well, apparently not.
PS: Back then I usually needed very different per-program env and not a
single, static env. So for me it made no sense to have a set of default
env and have tests add their own variables on-demand on top of the
default. The situation in gcc might be the exact opposite?
thanks,
