On Wed, 27 Sep 2023, Jeff Law wrote: > > IMO this is one of those places where we should just be as normal as > > possible. So if the other big ports allow system headers then we should, > > otherwise we should move everyone over to testing in some way we'll catch > > these before commit. > Exactly. I think the dance we've been doing with stdint-gcc.h is a bit silly, > but I haven't pushed on it at all. > > No other port does anything similar. When they need stdint.h, they include > it. It does mean you have to have the appropriate headers installed for each > multilib configuration, but that's the way every other port handles this > problem. There's no good reason I'm aware of for RISC-V to be different.
I agree that using standard system headers where required is a reasonable expectation, but I maintain that when using a non-default ABI/multilib by an explicit request of a test case, it is the responsibility of our test framework to verify that the chosen ABI/multilib is compatible with the environment. I think it should apply equally to all the tests whether they are run, link, or compilation tests. I think a requirement for a verifier to have headers for all the possible ABIs/multilibs installed is unreasonable. For a hosted target such as Linux/*BSD/whatever it may yet be feasible. For a bare-metal target it may not be possible, and in particular such a target may possibly support one specific ABI only and #error if an incompatible configuration is detected. This must not cause a test to FAIL, because GIGO. Overall I think an expectation ought to be for a given ABI/multilib to be verified by running the whole testsuite for the desired configuration, either by having it as the default for the toolchain under test or via an explicit target board option. I accept the desire to have alternative ABIs/multilibs smoke-tested by a couple of tests explicitly requesting them via a compilation option, to verify that the option works if nothing else. I think the burden of verifying the compatibility of the environment must not be on the individual tests, but the framework itself, and I think the MIPS framework fulfils the requirement, as it verifies the options given in the individual tests without the tests themselves having to request anything, they just list the compilation options they require the usual way via `dg-options'. I think that to verify the compatibility of ABI/multilib options for compilation tests we can pick up a system header we can reasonably expect to change depending on the ABI/multilib chosen, and therefore to pull any ABI/multilib-specific bits, such as <limits.h>. If a given environment turns out incompatible with a given ABI/multilib option, then all the tests requesting said option ought to be automatically demoted to UNSUPPORTED. Most importantly implementing this approach in our test framework is a one-off project, while requiring people to have their environment set up for ABI/multilib configurations they have no interest in would cause them continuous effort. Maciej
