public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "clyon at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4
Date: Mon, 20 Sep 2021 16:37:44 +0000	[thread overview]
Message-ID: <bug-102411-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411

            Bug ID: 102411
           Summary: arm/vfp18.c fails with -march=armv7e-m+fp for
                    cortex-m4
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

When running the testsuite with -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp and
simulating for cortex-m4, I noticed that gcc.target/arm/vfp18.c fails at
execution.

The testcase contains:
void myfunc(__fp16, float, double, float, __fp16, int) ;

int main()
{
  myfunc(1.0f, 2.0f, 4.0, 2.0f, 1.0f, 3);
....
}

The testcase is compiled with:
-mthumb -mfloat-abi=hard -march=armv7e-m+fp -mfpu=vfpv4 -mfp16-format=ieee

For main we generate:
        push    {r7, lr}        @ 27    [c=8 l=2]  *push_multi
        add     r7, sp, #0      @ 28    [c=4 l=4]  *arm_addsi3/4
        movs    r0, #3  @ 5     [c=4 l=2]  *thumb2_movsi_shortim
        movw    r3, #15360      @ 23    [c=4 l=8]  *movhf_vfp/6
        vmov    s5, r3  @ 6     [c=4 l=4]  *movhf_vfp/4
        vmov.f32        s4, #2.0e+0     @ 7     [c=4 l=4]  *thumb2_movsf_vfp/2
        vmov.f64        d1, #4.0e+0     @ 8     [c=4 l=4]  *thumb2_movdf_vfp/2
        vmov.f32        s1, #2.0e+0     @ 9     [c=4 l=4]  *thumb2_movsf_vfp/2
        vmov    s0, r3  @ 10    [c=4 l=4]  *movhf_vfp/4
        bl      myfunc          @ 11    [c=8 l=4]  *call_symbol
        movs    r3, #0  @ 12    [c=4 l=2]  *thumb2_movsi_shortim
        mov     r0, r3  @ 19    [c=4 l=2]  *thumb2_movsi_vfp/0
        pop     {r7, pc}        @ 31    [c=8 l=2] 
*pop_multiple_with_writeback_and_return

The problem is the vmov.f64 instruction which is not supported by cortex-m4
since it has a single-precision-only FPU.

Running under QEMU with -cpu cortex-m7 passes, as expected.

The problem comes from -mfpu=vfpv4, which is added by arm_fp16_hw (indirectly
from check_effective_target_arm_fp16_ok_nocache)

Indeed arm-cpus.in says:
begin fpu vfpv4
  isa VFPv4 FP_D32
end fpu vfpv4

so it enables double-precision support.


Looks like a testism, since we effectively override -march=armv7e-m+fp with
-mfpu=vfpv4, but maybe a warning would be helpful?
And something to disable the test or make it pass.

             reply	other threads:[~2021-09-20 16:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 16:37 clyon at gcc dot gnu.org [this message]
2021-09-20 18:13 ` [Bug target/102411] " rearnsha at gcc dot gnu.org

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=bug-102411-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).