On 1/26/2026 5:23 PM, Keith Packard wrote:
Each Compilation Driver program provides C++ code to manipulate the
build process. However, spec fragments must operate the same for every
driver.
This series introduces a new spec file function, %:if-driverlang,
which can be used to vary operation based upon the expected target
language for the driver.
Each driver is assigned a single target language from one of those
supported by the -x option -- gcc targets 'c', g++ targets 'c++'.
Drivers without a specific language, like 'jit', do not ever match.
I'm using this in the Debian embedded GCC ports to include exception
handling code and data when using g++, but leave it out when using
gcc.
Here's a brief example (included in invoke.texi)
*startfile:
crt0%O%s %:if-driverlang(c++ crtbegin%O%s)
This adds crtbegin.o only when linking with g++.
Other approaches I considered:
* Building gcc.cc once per driver. This would allow tm_file elements
to conditionalize their spec defines based upon the target driver.
* Having each driver insert a magic command line option that spec
fragments could look for with the existing %{ mechanism.
I also considered whether the drivers could match more than one
language; that's not actually useful as the goal is to modify behavior
based upon the driver selected, so you only need some way to identify
that. But, it means that the fortran driver only matches f77 and not
f95.
Possible extensions:
* Track '-x' options and use those to control this function too.
* Match a list of languages -- %:if-driverlang(c,c++ ...)
* Inverted match -- %:if-driverlang(!c++ ...).
Given the behavioral changes, this probably needs broader agreement and
wouldn't be appropriate for gcc-16. So I'm deferring.
jeff
