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 >>
