On 30/10/14 18:37, Mike Stump wrote:
On Oct 30, 2014, at 10:25 AM, Andrew Stubbs <a...@codesourcery.com>
wrote:
Many of the tests in gcc.target/powerpc specify an explicit -mcpu
option with dg-options.
So, I think this isn’t the strategy people like for this sort of
thing. The problem is default flags. You can have a certain cpu as
a target but no flag for it, no flag, no way to skip based upon that
flag.
I'm not sure what that last sentence is trying to say?
Default flags (as in flags that you don't see) ought not to be a problem
because an explicit flag should override them.
My problem is with the flags that select non-default multilibs. When you
run a test you get compile line like this:
<target>-gcc <dg-options> -mcpu=<multilib-cpu> foo.c
If <dg-options> contains only optimization options then all is well. If
it contains an mcpu option then you get conflicting options. The last
one will win, which will likely cause a test failure.
Extra test failures must be investigated, and when there's lot like this
then that's a huge time-sink. Either that or a real failure gets missed.
This might not be the best solution, but I really don't like the status
quo. If it's not this, what is it?
Also, I'm fairly dissatisfied with the current situation where a
test uses dg-require-effective-target to test the default target,
and then adds options that would change the result of that test; it
can cause a test to get skipped when actually it would work fine.
Anyway, that's a problem for a different day.
But, that code works the way you want it to? If you don’t want to
add a flag, you don’t.
I don't think you understood me. Consider this scenario:
/* { dg-require-effective-target powerpc_spe } */
/* { dg-options "-mcpu=8548 -mspe -mabi=spe" } */
If the selected multilib happens to be one that does not support SPE,
then this test will *not* be run, and yet, as soon as the dg-options
have been applied then the target will support SPE (if the compiler has
support at all).
The idiom appears repeatedly throughout the gcc.target tests. Anyway, I
had not tried to fix this. I had just noted that it can lead to
incomplete testing. It probably won't lead to false-fails unless
conflicting mcpu options happen to make scan-assembler tests mismatch.
One possible solution to both problems is to rewrite the tests like this
(and some tests do):
/* { dg-options "-mcpu=8548 -mspe -mabi=spe" } */
/* { dg-skip-if "not an SPE target" { ! powerpc_spe_nocache } { "*"
} { "" } } */
The downside is that "nocache" tests are much slower. It also requires
that there is a suitable feature test available. If it just checks that
the right cpu has been used then it's functionally identical to my
dg-skip-if patch.
And this still has the problem that multiple -mcpu flags can cause the
multilib selection to go wrong, which results in link errors.
Another possibility might be to invent "dg-remove-options" or
"dg-reset-options" that removes any multilib-selection option. The test
would run identically for all multilibs, but that's probably appropriate
in these cases.
Thoughts?
Andrew
