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)

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