public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "avieira at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main Date: Tue, 13 Oct 2020 09:51:44 +0000 [thread overview] Message-ID: <bug-97327-4-8MUYZV6ZEV@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-97327-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 --- Comment #5 from avieira at gcc dot gnu.org --- Your other one: -mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp This has cpu without mve and arch with mve. Another fun caveat to look at is in: -mcpu=cortex-m55 -mfloat-abi=soft float-abi=soft disables vector instructions, so it makes sense to remove mve.fp and fp.dp/fp. However, we must make sure that +mve is still passed to the assembler because +mve enables new scalar shift instructions. If we want to be in-sync with legacy though I don't think we even need to look at all these complicated cases as. Since it seems in the past we ignore fp extensions, take for instance: arm-none-eabi-gcc -mcpu=cortex-m7 -march=armv7e-m -mfloat-abi=hard arm-none-eabi-gcc -mcpu=cortex-m7 -march=armv7e-m+fp -mfloat-abi=hard arm-none-eabi-gcc -mcpu=cortex-m7+nofp -march=armv7e-m -mfloat-abi=soft arm-none-eabi-gcc -mcpu=cortex-m7+nofp -march=armv7e-m+fp None of these give the warning, so maybe the solution is to ignore MVE as well as the FP extension when checking for this? There is a bit in the warning code that says: /* And if the target ISA lacks floating point, ignore any extensions that depend on that. */ if (!bitmap_bit_p (target->isa, isa_bit_vfpv2)) bitmap_and_compl (isa_delta, isa_delta, isa_all_fpbits); Maybe we need to 'ignore any extension that depends on mve'? But I don't quite understand how this works with the case where we do have isa_bit_vfpv2... For Srinath's sake it would be good to agree on what the behaviour should be and then work towards that. I personally don't have a strong feeling about this other then: passing '-mcpu=cortex-m55' shouldn't give warnings ... since well that's insane :P
next prev parent reply other threads:[~2020-10-13 9:51 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-07 21:52 [Bug target/97327] New: " clyon at gcc dot gnu.org 2020-10-07 21:52 ` [Bug target/97327] " clyon at gcc dot gnu.org 2020-10-07 22:05 ` clyon at gcc dot gnu.org 2020-10-08 8:11 ` jgreenhalgh at gcc dot gnu.org 2020-10-09 9:50 ` sripar01 at gcc dot gnu.org 2020-10-13 9:14 ` avieira at gcc dot gnu.org 2020-10-13 9:22 ` clyon at gcc dot gnu.org 2020-10-13 9:33 ` avieira at gcc dot gnu.org 2020-10-13 9:51 ` avieira at gcc dot gnu.org [this message] 2020-10-16 13:54 ` cvs-commit at gcc dot gnu.org 2020-10-19 11:58 ` cvs-commit at gcc dot gnu.org 2020-10-19 12:06 ` sripar01 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-97327-4-8MUYZV6ZEV@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).