Fix pr61848, linux kernel miscompile

[Joseph S. Myers]

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
joseph@codesourcery.com