On 9/28/23 03:46, Maciej W. Rozycki wrote:
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.
No other target enforces this kind of requirement and I would maintain
that we shouldn't either.
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.
If you're testing options that you don't have headers/libraries for,
then that's a testsuite bug irrespective of bare metal vs linux. It's
been like that for about 30 years at this point. I fail to see why
RISC-V should be special in this regard.
Jeff
