On Tue, 16 Sep 2014, Alan Modra wrote: > gcc testsuite additions? I decline. It is too soon. If you had read > my patch submission you'll see that at some stage gcc was supposed to > warn on conflicting section attributes, but hasn't done so for a very > long time. There needs to be some agreement on which direction we > should go before I'm willing to spend even a small amount of time on > the testsuite. Also, a test for merging tls model attributes runs
The point of testsuite additions is to verify the visible changes in behavior intended to be caused by the patch (and, as applicable, that the behavior doesn't change in other related areas where it's not meant to change), rather than to test something that GCC doesn't do either before or after the patch. If the lack of tests is because the patch is an RFC about what the desired behavior is, rather than an actual submission for inclusion, then it's helpful to say so in the patch submission. > into the problem that this can only be done in a target independent > way by looking at dumps, and the tls model dump is currently broken. If there is a reason some aspect of the change can't readily be tested, that should be stated in the patch submission (along with examples of the affected code that can't readily be put into suitable form for the testsuite). > Come to think of it, what if I decline to make any testsuite > additions? I'm asking because you're a steering committee member, and Then the patch isn't ready for review. Documentation and testcases are the first thing I look at when reviewing C front-end changes; the testcases are the primary evidence that the patch does what it's meant to do, and without them I won't generally try to review the code changes. There's no requirement for test-driven development, but personally I prefer to write the documentation and tests before the rest of the patch (and make sure the tests do fail with the unmodified compiler, unless they are tests of related cases that already work but I want to make sure don't get broken) - though in the course of implementing the patch I expect to find other related cases that result in more tests being written, and to modify exactly what I expect from the tests I wrote earlier. (I also find it a pain when backporting patches to packages that don't expect testcases as a norm for all patches if the author didn't include testsuite coverage with their patch, as it makes it much harder to tell if the backport is working properly. Or if a problem was caused by a patch that was committed without testcases - again, it's hard to tell if a fix affects the fix to the original issue the patch was supposed to address.) -- Joseph S. Myers jos...@codesourcery.com
