[PATCH] RISC-V/testsuite: Fix ILP32 RVV failures from missing <gnu/stubs-ilp32d.h>

Jeff Law jeffreyalaw@gmail.com
Fri Sep 29 21:03:14 GMT 2023

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.


More information about the Gcc-patches mailing list