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); >>> +} >>> + >>
