public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4
@ 2021-09-20 16:37 clyon at gcc dot gnu.org
2021-09-20 18:13 ` [Bug target/102411] " rearnsha at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: clyon at gcc dot gnu.org @ 2021-09-20 16:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug target/102411] arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4
2021-09-20 16:37 [Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4 clyon at gcc dot gnu.org
@ 2021-09-20 18:13 ` rearnsha at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2021-09-20 18:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411
--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
The AAPCS tests are executable tests, so rely on a number of features of the
support libraries (ie libraries compatible with the options used for the
compilation). I don't think they should be adding any options to try and force
the test to compile. So I think the dg-add-options is just wrong.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-09-20 18:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-20 16:37 [Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4 clyon at gcc dot gnu.org
2021-09-20 18:13 ` [Bug target/102411] " rearnsha at gcc dot gnu.org
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).