On 09/16/14 00:03, 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.
I think the direction for this ought to be quite clear, warn if we've
got conflicting section attributes :-) One could make the argument that
if we had a test for conflicting section attributes that this code
wouldn't have bit-rotted so badly.
I think for #1 in your original message, we should be issuing a warning
of some kind as clearly something isn't right when we've asked for the
same object to be in two different sections.
Also, a test for merging tls model attributes runs
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.
Target independent tests are always best, but pulling together one that
is specific to a target is usually still good enough. Especially if
it's an x86 target given how often those are tested by the developer
community as a whole.
I think for #1 in your posting, verifying that we issue the proper
warning should be sufficient. Use the dg framework test and this marker:
/* { dg-require-named-sections } */
I'm not familiar enough with the TLS stuff to know what the right
behaviour ought to be.
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
set policy. I fully agree that testsuite additions are desirable,
but, is *requiring* such testsuite additions a good idea? Will that
really improve gcc over time? (Herding cats comes to mind. I think
you'll just drive away gcc contributors.)
There's no policy that requires testsuites, but for bugfixes most
maintainers ask for them, or at least an explanation why they can't be
provided.
GCC's testsuite is primarily a regression driven suite and these are
great examples of behavior regressions that never should have happened,
but did because of holes in the suite. That's obviously something we
ought to correct ;-)
Jeff