[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/26339] [aarch64] unknown architectural extensions

From: ktkachov at sourceware dot org
Subject: [Bug gas/26339] [aarch64] unknown architectural extensions
Date: Thu, 06 Aug 2020 16:44:16 +0000


Kyrill Tkachov <ktkachov at sourceware dot org> changed:

           What    |Removed                     |Added
                 CC|                            |ktkachov at sourceware dot org

--- Comment #2 from Kyrill Tkachov <ktkachov at sourceware dot org> ---
I think a problem we've got here is that in LLVM there are all these "backend
features" that do not correspond to the notional user-facing features in Clang,
but which are nevertheless exposed to users through the assembler and

Thus, GCC and Clang agree on +memtag being the option to enable MTE. But gas
follows GCC and uses +memtag to enable it, whereas in LLVM the "internal
feature" ends up being "+mte", which is what the assembler demands instead of

Similar for 'tlb-rmi', I think introduced through

Reading through the rationale at
it looks like LLVM made the conscious step of breaking compatibility with GNU,
which is unfortunate.

For the future, it would be great if both the Clang-level and the
assembly-level feature strings in LLVM aligned (and we can ensure they're
aligned with GCC and gas).

For the current inconsistencies, we have some options of resolving the pain.
LLVM can add +memtag as an alias for +mte to its "backend feature".

The other extension we need to resolve is 'tlb-rmi'. It is a mandatory part of
Armv8.4-A. It cannot be enabled at the Clang level, only at the assembler
level, as it's one of those "backend features". gas doesn't support the
extension string and gates these instructions on -march=armv8.4-a. I think that
behaviour is aligned with what LLVM did with

Any ideas on how to proceed?

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]