[PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

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

PING^1 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html

BR,
Kewen

on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote:
> 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);
> +}
> +

PING^2 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

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

PING^3 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

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

PING^4 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

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

PING^5 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html

I think this is a reasonable fix, the behavior is consistent with what we have in
the previous built-in framework, I'm going to push this a week later if no objections.  :)

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