Ah -- that makes things clearer thanks!
I appreciate suggesting that this shouldn't block the patchset.
I will take you up on that (as long as there's no other objections) --
so IIUC I'm waiting for RTEMS and nvptx testsuite runs and need to apply
the nits that Jakub suggested.
Obviously I would like to have a testsuite setup that works for everyone
pretty soon after I push the commits.
To get started on that -- I'd like to double-check that adding the
`et-static.def` stuff to the libgomp build system is the preferred
approach (as opposed to moving the definition into
`libgomp-test-support.exp.in`).
It seems like that's your preference @Thomas -- double-checking with
@Tobias, @Jakub and everyone else in the thread.
Cheers,
Matthew
On 10/15/26 15:23, Thomas Schwinge wrote:
External email: Use caution opening links or attachments
Hi!
On 2026-10-15T14:23:11+0100, Matthew Malcomson <[email protected]> wrote:
I'm surprised that this isn't working -- I wonder whether it's that
`site.exp` is not using an updated `libgomp-site-extra.exp` or that
`site.exp` is not getting run.
I'm sorry, I can't currently check what our internal testing system is
doing exactly, but from what I remember, it synthesizes its own
'site.exp', and doesn't consider 'libgomp-site-extra.exp' at all.
(I'm not saying the latter is the correct thing to do.)
That said, despite my wish to understand, I think using the framework in
commit that @Thomas pointed at is probably a better approach.
Ah -- I thought you were doing that already. Sorry for any confusion I
may have caused.
Anyway:
I.e. use the new `et-static.def` file to identify whether the
`futex_waitv` syscall was found instead of the current approach of
putting in `libgomp-site-extra.exp.in` and expecting the configure/make
cycle to put that into the testing environment.
On 2026-10-15T14:44:17+0100, Matthew Malcomson <[email protected]> wrote:
That said, maybe given that one can configure `libgomp` to avoid the
futex_waitv target even if the syscall exists
(`--disable-linux-futex-waitv`) that other framework might not be the
best match.
But the actual configuration should get reflected in the 'et-static.def'
file, so that should work, no?
Depending on what went wrong with Andrew's testing maybe I should move
the line getting autoconf to define `libgomp_config_path` into
`libgomp-test-support.exp.in` instead of `libgomp-site-extra.exp.in`?
That should work as well; out internal testing system does pay attention
to that file. (But I've not tested this.)
(And yes, there's potential to refactor all this...)
I'd say that resolving this should not block your patchset; the standard
build-tree testing ('make check') behaves as expected.
Grüße
Thomas
@Andrew -- do you know if the problem was that your testsuite run didn't
source the `site.exp` or that the build didn't create it?
Thanks,
MM
On 10/15/26 14:23, Matthew Malcomson wrote:
External email: Use caution opening links or attachments
Thanks very much for testing Andrew!
I'm surprised that this isn't working -- I wonder whether it's that
`site.exp` is not using an updated `libgomp-site-extra.exp` or that
`site.exp` is not getting run.
That said, despite my wish to understand, I think using the framework in
commit that @Thomas pointed at is probably a better approach.
I.e. use the new `et-static.def` file to identify whether the
`futex_waitv` syscall was found instead of the current approach of
putting in `libgomp-site-extra.exp.in` and expecting the configure/make
cycle to put that into the testing environment.
What do others think? Should I make this change?
MM
On 10/15/26 11:38, Thomas Schwinge wrote:
External email: Use caution opening links or attachments
Hi!
On 2026-10-15T11:01:36+0100, Andrew Stubbs <[email protected]> wrote:
I finally got to test this on amdgcn (apologies for the delay).
(Similarly, I still have to look into the GCC/nvptx changes.)
There were several instances of the following error:
libgomp.sum:ERROR: libgomp.c/barrier-copyprivate-task.c: can't read
"libgomp_config_path": no such variable for " dg-do 11 run { target
linux_futex_waitv } "
There's 30 similar messages across 15 testcases.
I suppose that's your testing harness not yet having been adjusted for
commit r17-2481-g55bca2dd38913274d6157fb2c7cd1edab0442c6d
"build: testsuite: Generate effective targets from auto-host.h".
Grüße
Thomas
Otherwise, there were no test issues.
Andrew
