On Wed, 14 Oct 2026, Jacob Bachmeyer wrote:
> > > > Note that being globally applicable *also* applies to the
> > > > GCC_EXEC_PREFIX
> > > > override (at least) in certain configurations on the host
> > > This looks like something that has a current solution. How is
> > > GCC_EXEC_PREFIX
> > > currently handled?
> > With testsuite save/restore logic that, as usual, only works when host =
> > build (so this particular sub-case, of build-tree testing but where
> > GCC_EXEC_PREFIX is needed to find some tools from the installed prefix,
> > wouldn't work for remote hosts).
>
> So these are situations in which GCC's testsuite currently fails to run, and
> we want to extend the framework to enable testing in these situations?
Yes.
> VAR:=VALUE looks to much like make's static assignment. VAR+=VALUE is
> generally used for /append/. Maybe the better option would be to allow
> "${VAR}" to appear in VALUE? Then prepending to PATH would simply be
> "PATH=/where/ever:${PATH}".
The colon is only meant to be there if the variable was already set. In
shell terms it's PATH=/where/ever${PATH+:${PATH}} - but I don't suggest
actually supporting such shell notation for the overrides. Maybe it would
be better to have something that explicitly names the kind of override
when it's not simply setting a value?
VAR=VALUE
VAR/undef
VAR/path-prepend=/where/ever
> > Extensions to the interface for default_target_assemble and default_link
> > are less obvious since they don't have such an argument taking arbitrary
> > key=value pairs at present.
>
> The interfaces are actually target_compile, target_assemble, etc. because
> default_target_compile, default_target_assemble, etc. are internal procedures
> that are documented as internal. Do not expect overriding them to reliably
> work and you should not call them directly from testsuite code. They will
> eventually disappear from the global namespace.
It's target_compile that GCC uses (via wrappers gcc_target_compile etc.).
> > "next test script" is liable to mean tens of thousands of tests were
> > skipped as a result of (typically) a syntax error in a dg.exp test
> > directive, which is functionally equivalent to the whole testsuite falling
> > over.
>
> Should dg.exp also catch errors and attempt to resume, then?
That would probably be friendlier to users, yes, in the case of a mistake
in a test directive.
--
Joseph S. Myers
[email protected]
