On 18/02/2025 15:32, Richard Sandiford wrote:
> Alfie Richards <alfie.richa...@arm.com> writes:
>> This changes the ambiguation error for C++ to cover cases of differently
>> annotated FMV function sets whose signatures only differ by their return
>> type.
>>
>> It also adds tests covering many FMV errors for Aarch64, including
>> redeclaration, and mixing target_clones and target_versions.
>
> The tests look good.  Sorry for not applying the series to find out
> for myself, but what's the full message for:
>> diff --git a/gcc/testsuite/g++.target/aarch64/mvc-error2.C b/gcc/testsuite/g++.target/aarch64/mvc-error2.C
>> new file mode 100644
>> index 00000000000..0e956e402d8
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.target/aarch64/mvc-error2.C
>> @@ -0,0 +1,10 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-ifunc "" } */
>> +/* { dg-options "-O0" } */
>> +/* { dg-additional-options "-Wno-experimental-fmv-target" } */
>> +
>> +__attribute__ ((target_clones ("default, dotprod"))) float
>> +foo () { return 3; } /* { dg-message "previously defined here" } */
>> +
>> +__attribute__ ((target_clones ("dotprod", "mve"))) float
>> +foo () { return 3; } /* { dg-error "redefinition of" } */
>
> ...the redefinition error here?  Does it mention dotprod specifically?
> If so, it might be worth capturing that in the test, so that we don't
> regress later.
No unfortunately the error is just:

../FMV_REWRITE/gcc/testsuite/g++.target/aarch64/mvc-error2.C:9:1: error: redefinition of ‘float foo()’
    9 | foo () { return 3; }
      | ^~~
../FMV_REWRITE/gcc/testsuite/g++.target/aarch64/mvc-error2.C:6:1: note: ‘float foo()’ previously defined here
    6 | foo () { return 3; }
      | ^~~

This is obviously not great.

I didn't do anything about this as all the ways I could think of to improve this are quite involved.

Currently this is handled by the common_function_version hook which only
indicates if the decl's are part of the same function version set or not. Then in this case where they're not distinct versions it tries to combine them (which fails) and then diagnoses the conflict as usual.

I think I've got a way to make this slightly better, which I will try.

Either way, I'll update the test for this for the next patch (I previously didn't know how to deal with the styling of the names but I've learnt from other tests now.)

> Thanks,
> Richard

Reply via email to