[Bug target/104482] ICE: Segmentation fault (in rs6000_builtin_type_compatible), or ICE: tree check: expected class 'type', have 'reference' (attr_addr_expr) in cp_type_quals, at cp/typeck.cc:10955

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:1a71881d05d3ec3e56492fff0197f88dcf4d9dbc

commit r12-8778-g1a71881d05d3ec3e56492fff0197f88dcf4d9dbc
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Sep 13 04:14:23 2022 -0500

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

    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.

            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.

    (cherry picked from commit 38db48346cc045ed5656233c42d01d6d06bffc35)