[Bug target/110255] New: arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

[Bug target/110255] New: arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

[stammark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255

            Bug ID: 110255
           Summary: arm: MVE intrinsics C++ polymorphism with
                    -flax-vector-conversions
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stammark at gcc dot gnu.org
  Target Milestone: ---

Hi all,
See: https://godbolt.org/z/53ME1fGfM

The compiler with the error is the one that is using -flax-vector-conversions
through the C++ frontend.
Unsure if this is something to do with the C++ front-end or something in the
target backend (and how the builtins are registered with the front-end).

This seems to happen regardless of if the vaddq intrinsic has been
"restructured" by Christophe's
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615997.html (so going back
to older GCC12,13 still gives the error), but another intrinsic, like vbicq,
doesn't give the error at all (although that has a different context of the
`int` immediate having to be a compile-time constant).
(clang handles all this fine FWIW)

Has anyone seen this kind of thing before, have any ideas on workarounds, or
have any insight on if this this invalid C++ to begin with?

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
My suggestion is yes it is ambigious because of -flax-vector-conversions . and
really don't use -flax-vector-conversions unless you can't fix the original
code.

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=88698

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See bug 88698 comment #3 about -flax-vector-conversions history and even some
history on clang.

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

[stammark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110255

Stam Markianos-Wright <stammark at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Stam Markianos-Wright <stammark at gcc dot gnu.org> ---
Aha! Thanks, Andrew, that makes sense. I'll go back to the original authors for
this and check if there's any good reason why they are using
-flax-vector-conversions and if they can just change their code :)

Also woops, the godbolt link I gave above was in the middle of me messing
around with casts. Here is a clean one: https://godbolt.org/z/c9vaas6P8 . And
indeed, casting to the "correct" scalar type for the intrinsic (in this case
uint16_t), does indeed make this work

However, this is sounding like this bugzilla should also go to RESOLVED
INVALID. Sorry for the false alarm!