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

[Iain Sandoe <iain@sandoe-acoustics.co.uk>]

Segher Boessenkool <segher@kernel.crashing.org> wrote:

> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>> On 12/4/19 2:50 PM, Segher Boessenkool wrote:
>>> It would be nice to keep *some* dfp test(s) to make sure we don't ICE.
>>> If we disabled all such tests already, like with this patch, we wouldn't
>>> have ICEd or seen this problem.  That can be a separate test of course
>>> (and could be outside gcc.target/powerpc/dfp/).
>> 
>> Sure, I can add a test in gcc.target/powerpc/ that uses both a builtin
>> and an overloaded builtin to make sure we don't ICE when DFP is disabled.
> 
> Great, thanks!

so that would be a/some dg-do compile test(s), then?
(presumably, gated on effective_target_dfp … see below)

>>> Making such changes to the testsuite needs testing on *all* subtargets :-(
>> 
>> Right.  I'll come up with a patch and hopefully Iain and David can test
>> on Darwin and AIX and I can test on Linux with --enable-decimal-float
>> and --disable-decimal-float.  That should cover the major subtargets and
>> if it works there, I'd expect it to work on the minor subtargets too.
> 
> Sure, this is just testsuite, that will work fine.  As long as there is
> a plan :-)

(on r278957, with the system assembler which doesn’t support DFP insns
 and gcc.target dfp.exp not yet renamed)

# Skip these tests for targets that don't support this extension.
if { ![check_effective_target_dfp] } {
    return;
}

Works on Darwin to skip the entire set  (not too much of a  surprise, since
it’s used for the GCC and G++ cases already).

---

It’s possible (even likely) that Darwin can be built with an assembler that
supports DFP instructions, even tho it has no OS support.  Usually, my policy
is that we would do compile tests then, since that excercises more code.

..but then we need to gate run tests on the availability of runtime support.

I see that the GCC and G++ testsuites have also….

# If the decimal float is supported in the compiler but not yet in the
# runtime, treat all tests as compile-only.
global dg-do-what-default
set save-dg-do-what-default ${dg-do-what-default}
if { ![check_effective_target_dfprt] } {
    verbose "dfp.exp: runtime support for decimal float does not exist" 2
    set dg-do-what-default compile
} else {
    verbose "dfp.exp: runtime support for decimal float exists, use it" 2
    set dg-do-what-default run
}
verbose "dfp.exp: dg-do-what-default is ${dg-do-what-default}” 2

Do you think there’s any merit in doing something like that here too?

(I guess a finer-grained alternative is check_effective_target_dfprt in any
 run-tests)

.. or I can just force a false return from effective_target_dfp as we
 do for other cases where assembler support does not imply system 
 support.

cheers
Iain