public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions Date: Wed, 18 Aug 2021 15:23:20 +0000 [thread overview] Message-ID: <bug-101723-4-pbGJmGa4z4@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-101723-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Richard Earnshaw <rearnsha@gcc.gnu.org>: https://gcc.gnu.org/g:c21ba5e57e49b870f1607944c0742e78feb7bc8d commit r11-8881-gc21ba5e57e49b870f1607944c0742e78feb7bc8d Author: Richard Earnshaw <rearnsha@arm.com> Date: Thu Jul 29 11:00:31 2021 +0100 arm: reorder assembler architecture directives [PR101723] A change to the way gas interprets the .fpu directive in binutils-2.34 means that issuing .fpu will clear any features set by .arch_extension that apply to the floating point or simd units. This unfortunately causes problems for more recent versions of the architecture because we currently emit .arch, .arch_extension and .fpu directives at different times and try to suppress redundant changes. This change addresses this by firstly unifying all the places where we emit these directives to a single block of code and secondly (re)emitting all the directives if any changes have been made to the target options. Whilst this is slightly more than the strict minimum it should be enough to catch all cases where a change could have happened. The new code also emits the directives in the order: .arch, .fpu, .arch_extension. This ensures that the additional architectural extensions are not removed by a later .fpu directive. Whilst writing this patch I also noticed that in the corner case where the last function to be compiled had a non-standard set of architecture flags, the assembler would add an incorrect set of derived attributes for the file as a whole. Instead of reflecting the command-line options it would reflect the flags from the last file in the function. To address this I've also added a call to re-emit the flags from the asm_file_end callback so the assembler will be in the correct state when it finishes processing the intput. There's some slight churn to the testsuite as a consequence of this, because previously we had a hack to suppress emitting a .fpu directive for one specific case, but with the new order this is no-longer necessary. gcc/ChangeLog: PR target/101723 * config/arm/arm-cpus.in (generic-armv7-a): Add quirk to suppress writing .cpu directive in asm output. * config/arm/arm.c (arm_identify_fpu_from_isa): New variable. (arm_last_printed_arch_string): Delete. (arm_last-printed_fpu_string): Delete. (arm_configure_build_target): If use of floating-point/SIMD is disabled, remove all fp/simd related features from the target ISA. (last_arm_targ_options): New variable. (arm_print_asm_arch_directives): Add new parameters. Change order of emitted directives and handle all cases here. (arm_file_start): Always call arm_print_asm_arch_directives, move all generation of .arch/.arch_extension here. (arm_file_end): Call arm_print_asm_arch. (arm_declare_function_name): Call arm_print_asm_arch_directives instead of printing .arch/.fpu directives directly. gcc/testsuite/ChangeLog: PR target/101723 * gcc.target/arm/cortex-m55-nofp-flag-hard.c: Update expected output. * gcc.target/arm/cortex-m55-nofp-flag-softfp.c: Likewise. * gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_fpu1.c: Convert to dg-do assemble. Add a non-no-op function body. * gcc.target/arm/mve/intrinsics/mve_fpu2.c: Likewise. * gcc.target/arm/pr98636.c (dg-options): Add -mfloat-abi=softfp. * gcc.target/arm/attr-neon.c: Tighten scan-assembler tests. * gcc.target/arm/attr-neon2.c: Use -Ofast, convert test to use check-function-bodies. * gcc.target/arm/attr-neon3.c: Likewise. * gcc.target/arm/pr69245.c: Tighten scan-assembler match, but allow multiple instances. * gcc.target/arm/pragma_fpu_attribute.c: Likewise. * gcc.target/arm/pragma_fpu_attribute_2.c: Likewise. (cherry picked from commit c1cdabe3aab817d95a8db00a8b5e9f6bcdea936f)
next prev parent reply other threads:[~2021-08-18 15:23 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-02 10:48 [Bug target/101723] New: " rearnsha at gcc dot gnu.org 2021-08-02 10:48 ` [Bug target/101723] " rearnsha at gcc dot gnu.org 2021-08-02 10:50 ` rearnsha at gcc dot gnu.org 2021-08-05 11:52 ` cvs-commit at gcc dot gnu.org 2021-08-06 14:07 ` cvs-commit at gcc dot gnu.org 2021-08-06 14:27 ` cvs-commit at gcc dot gnu.org 2021-08-18 15:23 ` cvs-commit at gcc dot gnu.org [this message] 2021-08-18 15:23 ` cvs-commit at gcc dot gnu.org 2021-08-18 15:23 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:31 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:32 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:32 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:41 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:41 ` cvs-commit at gcc dot gnu.org 2021-08-23 14:43 ` rearnsha at gcc dot gnu.org 2021-08-26 15:18 ` clyon at gcc dot gnu.org 2021-08-31 11:25 ` rearnsha at gcc dot gnu.org 2021-09-01 8:14 ` clyon at gcc dot gnu.org 2022-02-08 7:12 ` pinskia 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-101723-4-pbGJmGa4z4@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).