binutils used in question is 2.37, install.texi does not mention any binutils requirement for arm.

For background, I reported this some time ago: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584556.html

Is there a way to disable a specific multilib at configure time?

This sort of problem is going to keep occurring while we continue to have separate distributions of GCC and binutils.  There's no way around the fact that support for a new architecture in GCC needs an assembler that understands the new architecture.  This is true for all architectures, not just Arm.

If a users asks for all the architectural libraries to be built, then I don't see it as unreasonable to require an assembler that can support this as well, so the issue becomes one of documentation, where we might as well just say that the minimum requirements may be increased if you try to use anything beyond the default configuration of the compiler.  Anything more is going to result in a completely unwieldy mess of impenetrable dependencies.

I don't think there's a way to make the current multilib infrastructure ignore specific sub-architectures.  t-multilib is already extremely complex due to the need to reduce the number of variants to something just about tractable for the build system; adding yet more complexity to it would make it almost impossible to manage.

I guess it might be possible to make the multilib configure machinery rip out variants that fail during configure, but you'd still need to deal with the mappings and decide what to do if the compiler needed an unbuilt library version.  Dropping back to the default multilib would often be completely wrong as it might be an ABI change.

Note I don't see we are asking for "all the architectural libraries to be built",
we are using --enable-multilib --with-multilib-list=aprofile,rmprofile which
worked before (in GCC 11).  Maybe it's possible to split up aprofile more?
I guess we could patch in our own t-*profile...

Anyway, can you amend install.texi, specifically the section about
--with-multilib-list to mention the minimum required version of binutils
when using aprofile (I think rmprofile is happy w/o armv9 support)?

Yes, I will update docs, cheers!

(In reply to Przemyslaw Wirkus from comment #6)
> Yes, I will update docs, cheers!

Any update on this, please?

> Subject: [Bug target/104144] [12 Regression] build fails due to: Error: unknown
> architecture `armv9-a'
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144
>
> --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to
> Przemyslaw Wirkus from comment #6)
> > Yes, I will update docs, cheers!
>
> Any update on this, please?

Apologies,
Was recently ill (it's that famous thing) and still digging through TODOs.
Please give me a day or two to sort this out.

Kind regards,
Przemyslaw

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

The master branch has been updated by Richard Earnshaw <rearnsha@gcc.gnu.org>:

https://gcc.gnu.org/g:1210fd6e69e51516c935acc49e223fce14a0dd86

commit r12-8106-g1210fd6e69e51516c935acc49e223fce14a0dd86
Author: Przemyslaw Wirkus <Przemyslaw.Wirkus@arm.com>
Date:   Mon Apr 11 13:14:01 2022 +0100

    arm: remove unnecessary armv9-a multilib variant [PR104144]
    
    Remove the armv9-a specific multilib variants.  Instead, arrange to
    use either the armv8-a multilibs or the armv7-a versions, depeding on
    the configuration.  This eliminates the need to have a version of gas
    that understands --march=armv9-a when building GCC.  Very little, if
    anything in the standard libraries directly uses Armv9-a features
    anyway.
    
    Also remove the +crc variant rules for Armv9-a.  CRC is an implicit
    part of Armv9-a, so doesn't have a explicit feature to handle it.
    
    gcc/ChangeLog:
    
            PR target/104144
            * config/arm/t-aprofile (MULTI_ARCH_OPTS_A): Remove Armv9-a options.
            (MULTI_ARCH_DIRS_A): Remove Armv9-a diretories.
            (MULTILIB_REQUIRED): Don't require Armv9-a libraries.
            (MULTILIB_MATCHES): Treat Armv9-a as equivalent to Armv8-a.
            (MULTILIB_REUSE): Remove remap rules for Armv9-a.
            * config/arm/t-multilib (v9_a_nosimd_variants): Delete.
            (MULTILIB_MATCHES): Remove mappings for v9_a_nosimd_variants.
    
    gcc/testsuite/ChangeLog:
    
            PR target/104144
            * gcc.target/arm/multilib.exp: Updated tests.

Fixed, by adjusting the selection of multilibs that are needed.  There's no benefit to building armv9-a multilibs, so use those built for armv8-a.