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