On Wed, 16 Apr 2025, 03:17 Hans-Peter Nilsson, <h...@bitrange.com> wrote:
> On Tue, 8 Apr 2025, Patrick Palka wrote: > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > > It's not mentioned very often, but is a general rule: > > Pretty please, add new files for new tests, don't just edit > existing files. (For one: if they start failing, they look like > regressions.) > The reason we don't always do that is performance. Some of these ranges tests take several seconds to compile. Adding another small test to the end of the file doesn't increase that too much, because all the templates have already been compiled once. Adding a new file means compiling the whole thing (and doing the dejagnu startup checks) all over again. The libstdc++ tests are slow enough already, editing existing test files is a way to mitigate that. It's even worse for me, because I run every single test with three permutations in --target_board and then multiply that by up to seven -std modes. It's true that new failures in existing tests can look like regressions but that's usually a one-off cost that is easily resolved. Does it do any real harm apart from initially miscategorizing a bug? The ever-increasing size of the testsuite and the time it takes is a problem forever, not a one-off cost.
