public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrea Corallo <andrea.corallo@arm.com>
To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,  nd <nd@arm.com>
Subject: Re: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard
Date: Fri, 27 Nov 2020 11:31:52 +0100	[thread overview]
Message-ID: <gkrft4vt7jb.fsf@arm.com> (raw)
In-Reply-To: <gkrmtz4t67j.fsf@arm.com> (Andrea Corallo via Gcc-patches's message of "Thu, 26 Nov 2020 17:48:16 +0100")

Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes:

> "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
>
>> On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote:
>>> Hi all,
>>> 
>>> I'd like to submit the following simple patch to clean some Low Loop
>>> Overhead test failing on hard float configurations.
>>> 
>>> lob2.c and lob5.c are failing with: "'-mfloat-abi=hard': selected 
>>> processor lacks an FPU".
>>> 
>>> lob3.c and lob5.c got "-mfloat-abi=soft and -mfloat-abi=hard may not
>>> be used together".
>>> 
>>> Okay for trunk?
>>> 
>>> Thanks
>>>   Andrea
>>>   
>>> 
>>
>> I think it would be better to try to do this with suitable
>> require-effective-target rules (or something similar).  Forcing options
>> should generally be a last resort and in particular using -mfpu should
>> really be avoided as we're trying to move away from that.
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/lob4.c
>> b/gcc/testsuite/gcc.target/arm/lob4.c
>> ...
>> -/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
>> "-marm" "-mcpu=*" } } */
>> +/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
>> "-marm" "-mcpu=*" "-mfloat-abi=hard" } } */
>>  /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps
>> -mfloat-abi=soft" } */
>>  /* { dg-require-effective-target arm_softfloat } */
>>
>> Why is the effective target arm_softfloat not solving this particular
>> conflict?
>
> Good point,
>
> I see is because we are defining __SOFTFP__ when compiling with
> '-march=armv8.1-m.main+mve -mfloat-abi=hard'.
>
> This sounds like a bug to me, correct?

Hi Richard,

diving into it further I've been explained by a knowledgeable colleague
that '__SOFTFP__' indicates the use of emulated FP operations but says
nothing about the ABI, indeed this last is what we want to check here to
avoid the conflict.

OTOH our selector 'arm_softfloat' IIUC is claimed to select the ABI [1]

"ARM target uses the soft-float ABI with no floating-point instructions
used whatsoever (as selected with -mfloat-abi=soft). "

but is looking at '__SOFTFP__'.

What should be the right fix then?

Should we leave the skip "-mfloat-abi=hard" into the patch and update
the doc of the selector?

Thanks

  Andrea


[1] https://gcc.gnu.org/onlinedocs/gccint/Effective-Target-Keywords.html

  reply	other threads:[~2020-11-27 10:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 13:53 Andrea Corallo
2020-11-26 14:34 ` Richard Earnshaw (lists)
2020-11-26 16:48   ` Andrea Corallo
2020-11-27 10:31     ` Andrea Corallo [this message]
2020-12-01 10:12       ` [PATCH V2] " Andrea Corallo
2020-12-08 11:09         ` Andrea Corallo
2020-12-11 11:21         ` Kyrylo Tkachov
2020-12-11 14:25           ` Andrea Corallo
2020-11-26 14:34 ` [PATCH] " Kyrylo Tkachov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=gkrft4vt7jb.fsf@arm.com \
    --to=andrea.corallo@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).