[PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Richard Sandiford]

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