Re: [PATCH] rs6000: Fix 2 for PR92661, Do not define builtins that overload disabled builtins

[Peter Bergner <bergner@linux.ibm.com>]

On 12/4/19 1:16 PM, Segher Boessenkool wrote:
> For future patches: it is much easier to review if you make the big,
> mechanical move a separate (earlier) patch.

Will do.




>> I have also
>> included a small patch to disable running the powerpc/dfp/ tests even for
>> powerpc*-linux when --disable-decimal-float is used.
> 
> What is the reason for that?
[snip]
> 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).
> 
> 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.?  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???



> Okay for trunk minus the changes to powerpc-dfp.exp (we can iterate on
> that).  Thanks!

Ok, I committed that part of the patch.  Thanks!

Peter