On 20/11/2024 15:04, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-20 15:53, Richard Earnshaw (lists) wrote:
>> On 20/11/2024 13:00, Torbjorn SVENSSON wrote:
>>>
>>>
>>> On 2024-11-19 18:57, Richard Earnshaw (lists) wrote:
>>>> On 19/11/2024 10:24, Torbjörn SVENSSON wrote:
>>>>> Update test case to use -mcpu=unset/-march=unset feature introduced in
>>>>> r15-3606-g7d6c6a0d15c.
>>>>>
>>>>> gcc/testsuite/ChangeLog:
>>>>>
>>>>> * gcc.target/arm/lto/pr96939_0.c: Use effective-target
>>>>> arm_arch_v8a.
>>>>> * gcc.target/arm/lto/pr96939_1.c: Remove dg-options.
>>>>>
>>>>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
>>>>> ---
>>>>> gcc/testsuite/gcc.target/arm/lto/pr96939_0.c | 4 ++--
>>>>> gcc/testsuite/gcc.target/arm/lto/pr96939_1.c | 1 -
>>>>> 2 files changed, 2 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/gcc/testsuite/gcc.target/arm/lto/pr96939_0.c
>>>>> b/gcc/testsuite/gcc.target/arm/lto/pr96939_0.c
>>>>> index 241ffd5da0a..3bb74bd1a1d 100644
>>>>> --- a/gcc/testsuite/gcc.target/arm/lto/pr96939_0.c
>>>>> +++ b/gcc/testsuite/gcc.target/arm/lto/pr96939_0.c
>>>>> @@ -1,7 +1,7 @@
>>>>> /* PR target/96939 */
>>>>> /* { dg-lto-do link } */
>>>>> -/* { dg-require-effective-target arm_arch_v8a_ok } */
>>>>> -/* { dg-lto-options { { -flto -O2 } } } */
>>>>> +/* { dg-require-effective-target arm_arch_v8a_link } */
>>>>> +/* { dg-lto-options { { -flto -O2 -mcpu=unset -march=armv8-a+simd+crc }
>>>>> } } */
>>>>> extern unsigned crc (unsigned, const void *);
>>>>> typedef unsigned (*fnptr) (unsigned, const void *);
>>>>> diff --git a/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
>>>>> b/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
>>>>> index 4afdbdaf5ad..c641b5580ab 100644
>>>>> --- a/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
>>>>> +++ b/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
>>>>> @@ -1,5 +1,4 @@
>>>>> /* PR target/96939 */
>>>>> -/* { dg-options "-march=armv8-a+simd+crc" } */
>>>>> #include <arm_acle.h>
>>>>>
>>>>
>>>> I'm not sure this is right. The PR talks about handling streaming in of
>>>> objects built with different options, which are supposed to be recorded in
>>>> the streaming data. But your change alters what will be recorded AFAICT.
>>>
>>> I was unsure what path I should take to address this test case.
>>> Maybe we should go with the following:
>>>
>>> gcc.target/arm/lto/pr96939_0.c:
>>> /* { dg-lto-do link } */
>>> /* { dg-require-effective-target arm_arch_v8a_link } */
>>> /* { dg-lto-options { { -flto -O2 } } } */
>>>
>>> gcc.target/arm/lto/pr96939_1.c:
>>> /* { dg-options "-mcpu=unset -march=armv8-a+simd+crc -mfpu=auto" } */
>>>
>>
>> Yes, that looks about right.
>>
>>>
>>> Should I also define an effective-target for arm_arch_v8a_crc that checks
>>> using -march=armv8-a+crc+simd -mfpu=auto -mfloat-abi=softfp and add
>>> dg-r-e-t for it in the pr96939_0.c file? Or is it safe to assume that this
>>> architecture is available if v8a is available?
>>
>> LTO tests are slightly special as the require multiple source files to be
>> compiled in the test. I don't think it would really work to have different
>> effective targets for the _1.c files compared to the _0.c files.
>
> No, it sounds strange to have different architectures flags.
>
>>
>>>
>>> Keep in mind that I cannot rely on dg-add-otions in an LTO test.
>>> Do we want to run this is -mfloat-abi=softfp or -mfloat-abi=hard mode?
>>
>> I would just copy any -mfloat-abi value that exists in v8a_link (which by
>> the looks of things is none). The two files must be compiled with the same
>> ABI or the link will fail.
>
> So, should I add -mfloat-abi=softfp to the arm_arch_v8a effective-target
> definition to allow the require check fail for a hard only build?
For the moment I'd try to avoid that. It risks changing the behaviour of any
existing tests that use that effective target. I'd stick with not overriding
the float ABI at all, as that provides the greatest chance that the link test
will work with the available multilibs. Nothing in this test really requires a
specific float ABI, it's all integer code.
R.
>
>>
>> We don't normally add many comments (other than dg- directives) to tests,
>> but in this case one might be worthwhile about the need for the options to
>> remain compatible at the ABI level.
>
> I agree.
>
> Kind regards,
> Torbjörn
>>
>> R.
>>
>>>
>>> Kind regards
>>> Torbjörn
>>>>
>>>> R.
>>>
>>
>
