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.
next 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: linkBe 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).