From: Iain Sandoe <iain@sandoe.co.uk>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: Arm assembler crc issue
Date: Thu, 19 Oct 2023 22:58:10 +0100 [thread overview]
Message-ID: <38EDD868-06D5-46D7-B40B-5BC20FF55B74@sandoe.co.uk> (raw)
In-Reply-To: <mptv8b2mgeu.fsf@arm.com>
Hi Richard,
> On 19 Oct 2023, at 22:49, Richard Sandiford <richard.sandiford@arm.com> wrote:
> Iain Sandoe <iain@sandoe.co.uk> writes:
>> I am being bitten by a problem that falls out from the code that emits
>>
>> .arch Armv8.n-a+crc
>>
>> when the arch is less than Armv8-r.
>> The code that does this, in gcc/common/config/aarch64 is quite recent (2022-09).
>
> Heh. A workaround for one assembler bug triggers another assembler bug.
Indeed … the good news is that the LLVM bug seems fixed on current release (17) and main.
The bad news is that it will likely take some to percolate through (and it won’t help released
toolsets anyway).
<snip>
>> So, it seems that this ought to be a reasonable configure test:
>>
>> .arch armv8.2-a
>> .text
>> m:
>> crc32b w0, w1, w2
>>
>> and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to assemble which can be used to make the +crc emit conditional on a broken assembler.
>
> AIUI the problem was in the CPU descriptions, so I don't think this
> would test for the old gas bug that is being worked around.
I see,
> Perhaps instead we could have a configure test for the bug that you've
> found, and disable the crc workaround if so?
OK - I’ll work in that direction, thanks
Iain
>
> Thanks,
> Richard
>
>>
>> - I am asking here before constructing the patch, in case there’s some reason that doing this at configure time is not acceptable.
>>
>> thanks
>> Iain
prev parent reply other threads:[~2023-10-19 21:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 16:41 Iain Sandoe
2023-10-19 17:06 ` Iain Sandoe
2023-10-19 21:49 ` Richard Sandiford
2023-10-19 21:58 ` Iain Sandoe [this message]
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=38EDD868-06D5-46D7-B40B-5BC20FF55B74@sandoe.co.uk \
--to=iain@sandoe.co.uk \
--cc=gcc@gcc.gnu.org \
--cc=richard.sandiford@arm.com \
/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).