Peter Bergner <berg...@linux.ibm.com> wrote:
On 12/4/19 1:16 PM, Segher Boessenkool wrote:
This isn't run from powerpc.exp, so it needs to still do that first check.
And it's up to the Darwin maintainers whether they want that second part
(there are many more tests and testsuites that disable *-darwin* while
that isn't really necessary).
As Peter mentions below, it produces a lot of meaningless FAILs if we run
the tests on Darwin, so one way or another, I’d like to skip them
(unless/until
we have a situation that DFP is supported on some hardware running
Darwin)...
Why do you need/want the check_effective_target_dfp test? If for example
this is to prevent ICEs, that is no good, that is *hiding* problems.
I suspect it is to stop the testsuite from complaining if you configure
with --disable-decimal-float. What is different there then, compared to
targets that do actually not support decimal float?
Well, yes. I saw those tests being run for my --disable-decimal-float
runs, which resulted in FAILs for all of those tests. They had ICE's
on unpatched trunk and FAILed gracefully using my patch, but they all
still FAILed, since these are DFP tests and DFP is disabled.
There's no sense in running these tests when DFP is disabled, either
manually due to --disable-decimal-float or implicitly because of the
specific target.
Why isn't just testing check_effective_target_dfp enough to disable the
tests on Darwin, --disable-decimal-float, etc.?
… It should be a better solution - I will confirm this.
That would seem to imply
that one of those targets we're testing against enables DFP, but somehow
we don't want to run the tests or they all still FAIL for some reason???
no idea about that (not something I encountered anyway).
Iain
