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

Peter Bergner bergner@linux.ibm.com
Thu Dec 5 16:06:00 GMT 2019


On 12/5/19 2:44 AM, Iain Sandoe wrote:
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>>> 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)

Yes, only a dg-do compile test.  For DFP enabled targets, they shouldn't
see any errors at all and for DFP disabled targets, I'd insert some
dg-error checks gated on ![check_effective_target_dfp] looking for the
"error: decimal floating-point not supported for this target" errors.
Any ICE would flag a real test case error.


> (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).

Great, thanks for checking.


> 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.

My --disable-decimal-float run also worked and I had an assembler that
supports all of the DFP insns, so I'd expect it to work for you too.
The check_effective_target_dfp tests really is checking for whether the
DFP modes exist in the compiler and that isn't gated on the assembler...
at least fully.




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

There exists check_effective_target_dfprt for that.



> 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?

Adding this to powerpc/dfp/dfp.exp won't do anything, since all of the
powerpc/dfp/ tests are dg-do compile tests.


> (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.

I've already verified that if decimal float is disabled, but you do
have an assembler that supports dfp insns, check_effective_target_dfp
still works correctly.


Peter



More information about the Gcc-patches mailing list