On 10/11/23 04:39, Florian Weimer wrote:
I've started to look at what it is required to convert the testsuite to
C99 (without implicit ints, without implicit function declarations, and
a few other legacy language features).
I bet those older tests originating from c-torture will be a bit
painful. Torbjorn liked having them minimized, to the point of
squashing out nearly everything he considered extraneous. I'd bet many
of those older tests are going to need lots of changes.
I plan to bundle a bunch of fixes together and submit patches
incrementally. So far, I have identified the following change
categories:
* C89 test cases that appear to make explicit use of C89-only features.
I plan to add /* { dg-additional-options "-std=gnu89" } */ to those
(or add -std=gnu89 to an existing dg-options line). These fixes can
be submitted early.
Sounds quite sensible.
* Overly reduced test cases where I can verify that the less-reduced
test case still reproduces the bug. Can be submitted early.
Seems like this could be a huge time sink, but that's your call.
* Similar test cases where I cannot verify that the test case is still
reproducing the bug, but where I assume that the unreduction is
harmless as far as the test objective is concerned. Can be submitted
early (but should be in a separate patch from the previous one).
I suspect many of the older tests will fall into this bucket.
* Test cases which have to build with -fpermissive. These include
expected-warnings tests, and over-reduced test cases where unreducing
might conceivably interfere with the test objective. These fixes have
to wait until -fpermissive for C lands (or they could wait until the
first relevant use of permerror).
Also seems quite sensible.
* Test cases which check (for example) error locations from diagnostics
that used be warnings, but that are now errors, and other test cases
where it seems to make sense to test for errors now. Here I plan to
change dg-warning into dg-error as appropriate. These changes would
be submitted along the patch that introduces the relevant permerror
calls. In some cases, I plan to duplicate tests into warning variants
(now with -fpermissive) and error variants (with dg-warning changed to
dg-error).
Sure, this seems quite sensible as well.
* There's the matter of target-specific tests that I don't know how to
cover. I can probably run the testsuite on x86-64, POWER9 and
AArch64, but beyond that, I'm pretty much out of options. I will have
to rely on help from the community, and perhaps target maintainers
adjusting their tests after the permerror changes according to the
principles above.
The good news is we'll see these pop in the tester for all those
embedded targets. So I'm not too concerned here.
Seems like a lot of (long needed) maintenance work. I can't drive it,
but I can certainly help with identification and fixing of the embedded
targets when we get to that point.
jeff
