I think the read of the room is that people think it would be generally useful, so let approve the general plan.
So, now we are down to the fine details. Please do see just how far you can stretch the existing mechanisms to cover what you need to do. I think the existing mechanisms should be able to cover it all; but the devil is in the details and those matter. For the suggestion to isolate the tests into their own area easily distinguished by filename, I think it is better to choose an original home for them using the existing naming scheme as much as possible, that way when fixed, they are already in the right spot. We in theory can move them around, but, there is a beauty in having a long term stable name that just doesn't change any. You can look through time to see all state changes. git log file.C, show you all the history nicely, and so on. You can experiment with dg-prms-id and see if that lets you tag in bug report numbers in a more meaningful way. Anyway, would be good to always include the bug report number in the test case, and in the bug report, add the name of the added test case (so others don't add yet another instance of the bug). So with that as a backdrop, I think it's reasonable to self-approve additions of this sort to the test suite. If you have test cases that can go in with existing mechanisms, feel free to start adding them in. As you find it difficult to express a test using the existing mechanisms, let's talk about those and see if anyone has a good idea on how to express it. I think ICEs are the most annoying to manage, but, I think excess and prune should be able to handle them. I think should get an error or warning, or should not get an error or warning are more trivial to manage. A word of caution, if we produce core files, before you add tons of core file producing test cases, you'll want to submit a, ulimit -c 0 patch that can avoid the issue. corefile writing is slow and consumes disk. I can't recall at the moment if the current infrastructure will reliably avoid core files. If test cases infinitely loop, timeout, consume all available ram, fill the disk, crash the host machine, or do other really nasty stuff, please, let's avoid those for now. It is mazing host fast testing goes on a 200 thread count box, and how slow it can go if a single test case needs to time out. If you start with the idea that any individual test case should only take 2-10 seconds, you won't go wrong.
