Alfie Richards <alfie.richa...@arm.com> writes:
> 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.
Sounds good! I don't think this is a blocker, so no worries if it
turns out to be too awkward. I was just curious.
Thanks,
Richard
