Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
BR, Kewen >>>> Hi, >>>> >>>> As PR104482 shown, it's one regression about the handlings when >>>> the argument number is more than the one of built-in function >>>> prototype. The new bif support only catches the case that the >>>> argument number is less than the one of function prototype, but >>>> it misses the case that the argument number is more than the one >>>> of function prototype. Because it uses "n != expected_args", >>>> n is updated in >>>> >>>> for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs; >>>> fnargs = TREE_CHAIN (fnargs), n++) >>>> >>>> , it's restricted to be less than or equal to expected_args with >>>> the guard !VOID_TYPE_P (TREE_VALUE (fnargs)), so it's wrong. >>>> >>>> The fix is to use nargs instead, also move the checking hunk's >>>> location ahead to avoid useless further scanning when the counts >>>> mismatch. >>>> >>>> Bootstrapped and regtested on powerpc64-linux-gnu P8 and >>>> powerpc64le-linux-gnu P9 and P10. >>>> >>>> v3: Update test case with dg-excess-errors. >>>> >>>> v2: Add one test case and refine commit logs. >>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593155.html >>>> >>>> v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html >>>> >>>> Is it ok for trunk? >>>> >>>> BR, >>>> Kewen >>>> ----- >>>> PR target/104482 >>>> >>>> gcc/ChangeLog: >>>> >>>> * config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin): Fix >>>> the equality check for argument number, and move this hunk ahead. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> * gcc.target/powerpc/pr104482.c: New test. >>>> --- >>>> gcc/config/rs6000/rs6000-c.cc | 60 ++++++++++----------- >>>> gcc/testsuite/gcc.target/powerpc/pr104482.c | 16 ++++++ >>>> 2 files changed, 46 insertions(+), 30 deletions(-) >>>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr104482.c >>>> >>>> diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc >>>> index 9c8cbd7a66e..61881f29230 100644 >>>> --- a/gcc/config/rs6000/rs6000-c.cc >>>> +++ b/gcc/config/rs6000/rs6000-c.cc >>>> @@ -1756,6 +1756,36 @@ altivec_resolve_overloaded_builtin (location_t loc, >>>> tree fndecl, >>>> vec<tree, va_gc> *arglist = static_cast<vec<tree, va_gc> *> >>>> (passed_arglist); >>>> unsigned int nargs = vec_safe_length (arglist); >>>> >>>> + /* If the number of arguments did not match the prototype, return NULL >>>> + and the generic code will issue the appropriate error message. Skip >>>> + this test for functions where we don't fully describe all the >>>> possible >>>> + overload signatures in rs6000-overload.def (because they aren't >>>> relevant >>>> + to the expansion here). If we don't, we get confusing error >>>> messages. */ >>>> + /* As an example, for vec_splats we have: >>>> + >>>> +; There are no actual builtins for vec_splats. There is special handling >>>> for >>>> +; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the >>>> call >>>> +; is replaced by a constructor. The single overload here causes >>>> +; __builtin_vec_splats to be registered with the front end so that can >>>> happen. >>>> +[VEC_SPLATS, vec_splats, __builtin_vec_splats] >>>> + vsi __builtin_vec_splats (vsi); >>>> + ABS_V4SI SPLATS_FAKERY >>>> + >>>> + So even though __builtin_vec_splats accepts all vector types, the >>>> + infrastructure cheats and just records one prototype. We end up >>>> getting >>>> + an error message that refers to this specific prototype even when we >>>> + are handling a different argument type. That is completely confusing >>>> + to the user, so it's best to let these cases be handled individually >>>> + in the resolve_vec_splats, etc., helper functions. */ >>>> + >>>> + if (expected_args != nargs >>>> + && !(fcode == RS6000_OVLD_VEC_PROMOTE >>>> + || fcode == RS6000_OVLD_VEC_SPLATS >>>> + || fcode == RS6000_OVLD_VEC_EXTRACT >>>> + || fcode == RS6000_OVLD_VEC_INSERT >>>> + || fcode == RS6000_OVLD_VEC_STEP)) >>>> + return NULL; >>>> + >>>> for (n = 0; >>>> !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs; >>>> fnargs = TREE_CHAIN (fnargs), n++) >>>> @@ -1816,36 +1846,6 @@ altivec_resolve_overloaded_builtin (location_t loc, >>>> tree fndecl, >>>> types[n] = type; >>>> } >>>> >>>> - /* If the number of arguments did not match the prototype, return NULL >>>> - and the generic code will issue the appropriate error message. Skip >>>> - this test for functions where we don't fully describe all the >>>> possible >>>> - overload signatures in rs6000-overload.def (because they aren't >>>> relevant >>>> - to the expansion here). If we don't, we get confusing error >>>> messages. */ >>>> - /* As an example, for vec_splats we have: >>>> - >>>> -; There are no actual builtins for vec_splats. There is special handling >>>> for >>>> -; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the >>>> call >>>> -; is replaced by a constructor. The single overload here causes >>>> -; __builtin_vec_splats to be registered with the front end so that can >>>> happen. >>>> -[VEC_SPLATS, vec_splats, __builtin_vec_splats] >>>> - vsi __builtin_vec_splats (vsi); >>>> - ABS_V4SI SPLATS_FAKERY >>>> - >>>> - So even though __builtin_vec_splats accepts all vector types, the >>>> - infrastructure cheats and just records one prototype. We end up >>>> getting >>>> - an error message that refers to this specific prototype even when we >>>> - are handling a different argument type. That is completely confusing >>>> - to the user, so it's best to let these cases be handled individually >>>> - in the resolve_vec_splats, etc., helper functions. */ >>>> - >>>> - if (n != expected_args >>>> - && !(fcode == RS6000_OVLD_VEC_PROMOTE >>>> - || fcode == RS6000_OVLD_VEC_SPLATS >>>> - || fcode == RS6000_OVLD_VEC_EXTRACT >>>> - || fcode == RS6000_OVLD_VEC_INSERT >>>> - || fcode == RS6000_OVLD_VEC_STEP)) >>>> - return NULL; >>>> - >>>> /* Some overloads require special handling. */ >>>> tree returned_expr = NULL; >>>> resolution res = unresolved; >>>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr104482.c >>>> b/gcc/testsuite/gcc.target/powerpc/pr104482.c >>>> new file mode 100644 >>>> index 00000000000..92191265e4c >>>> --- /dev/null >>>> +++ b/gcc/testsuite/gcc.target/powerpc/pr104482.c >>>> @@ -0,0 +1,16 @@ >>>> +/* { dg-require-effective-target powerpc_vsx_ok } */ >>>> +/* { dg-options "-mvsx" } */ >>>> + >>>> +/* It's to verify no ICE here, ignore error messages about >>>> + mismatch argument number since they are not test points >>>> + here. */ >>>> +/* { dg-excess-errors "pr104482" } */ >>>> + >>>> +__attribute__ ((altivec (vector__))) int vsi; >>>> + >>>> +double >>>> +testXXPERMDI (void) >>>> +{ >>>> + return __builtin_vsx_xxpermdi (vsi, vsi, 2, 4); >>>> +} >>>> + >>>
