public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Vladimir Makarov <vmakarov@redhat.com>
Cc: Christophe Lyon <christophe.lyon@linaro.org>,
	Vladimir Makarov via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64
Date: Tue, 23 Mar 2021 21:33:41 +0000	[thread overview]
Message-ID: <mptblb9v9l6.fsf@arm.com> (raw)
In-Reply-To: <758f391e-4ab2-e910-618d-d3a70d4a57c3@redhat.com> (Vladimir Makarov's message of "Tue, 23 Mar 2021 16:22:16 -0400")

Vladimir Makarov <vmakarov@redhat.com> writes:
> On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
>>
>> On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
>>> On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov <vmakarov@redhat.com> 
>>> wrote:
>>>>
>>>> Can you check?
>>>>
>>>> Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
>>>> and I don't see the regressions mentioned above.
>>>>
>>>> Can you check this too and if I am doing something wrong for testing,
>>>> please point me out.
>>>>
>>> I'm testing with cross-compilers with ST hat, but I'm not the only one
>>> seeing these failures, see gcc-testresults.
>>> Andreas and in Linaro we are both testing native compilers.
>>>
>>> These tests are driven by aarch64-sve-acle-asm.exp
>>>
>>> Is it possible that the binutils version matters? I'm using 2.34 for
>>> the cross-toolchains.
>>>
>> Sorry, I looked at the tests in more details.  They require 
>> aarch64_asm_f64mm and gcc114.fsffrance.org is not that kind of 
>> machine.  Therefore they are not even compiled on this machine. As I 
>> understand the tests should check the right assembler generation but 
>> the tests require to be run.
>>
>> The problem can be in necessity to use more relaxed memory constraints 
>> for aarch64.
>>
>> I'll investigate the regressions more.
>>
>>
>
> Here is the patch solving the problem.
>
> Also although asm tests only checks assembler code, a lot of them use 
> dg-require-effective-target and therefore can not be tested on other 
> aarch64 machines.  So the patch removes them.

I think they're still needed.  The harness tries to use assemble
rather than compile tests by default, so that the assembler picks
up any invalid instructions.  However, we can't assume that everyone
has a version of binutils that supports SVE and .variant_pcs, so the
tests fall back to compile tests unless:

if { [check_effective_target_aarch64_asm_sve_ok]
     && [check_effective_target_aarch64_variant_pcs] } {

is true.

However, the same problem then occurs for features that were added
by later architecture revisions, such as the ones being tested here.
Not everyone will have an assembler that understands these newer
instructions.

So the dg-require-effective-target are needed for the case in which
the system assembler is recent enough to support SVE but is not
recent enough to support these other extensions.

In other words, it wasn't your fault that these regressions didn't
show up.  But the fact that they didn't show up is kind-of deliberate,
since the testing provided by the assembler is a really useful sanity
check in this context.

The constraints.md patch is OK though.  Thanks for the quick fix.

Richard

  reply	other threads:[~2021-03-23 21:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 14:21 Vladimir Makarov
2021-03-19 15:03 ` Alex Coplan
2021-03-19 15:19   ` Jakub Jelinek
2021-03-19 15:41   ` Vladimir Makarov
2021-03-19 15:42 ` Richard Sandiford
2021-03-19 15:54   ` Jakub Jelinek
2021-03-19 16:10   ` Vladimir Makarov
2021-03-21 12:51     ` Richard Sandiford
2021-03-22 17:38       ` Vladimir Makarov
2021-03-23 13:07         ` Christophe Lyon
2021-03-23 16:54           ` Vladimir Makarov
2021-03-23 17:55             ` Christophe Lyon
2021-03-23 18:24               ` Vladimir Makarov
2021-03-23 20:22                 ` Vladimir Makarov
2021-03-23 21:33                   ` Richard Sandiford [this message]
2021-03-23 22:00                     ` Vladimir Makarov

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=mptblb9v9l6.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=vmakarov@redhat.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).