[Bug middle-end/103643] [12 Regression][OpenMP] ICE in create_tmp_var, at gimple-expr.c:482 - via gimplify_omp_affinity

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

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Chung-Lin Tang <cltang@gcc.gnu.org>:

https://gcc.gnu.org/g:62c8b21d48ab6012ddc50529a39071d902dba31a

commit r12-6200-g62c8b21d48ab6012ddc50529a39071d902dba31a
Author: Chung-Lin Tang <cltang@codesourcery.com>
Date:   Tue Jan 4 15:37:15 2022 +0800

    openmp: Fix ICE in gimplify_omp_affinity [PR103643]

    After the PR90030 patch, which removes the universal casting of all Fortran
    array pointers to 'c_char*', a Fortran descriptor based array passed into
an
    affinity() clause now looks like:

    -     #pragma omp task private(i) shared(b) affinity(*(c_char *) a.data)
    +     #pragma omp task private(i) shared(b) affinity(*(integer(kind=4)[0:]
* restrict) a.data)

    The 'integer(kind=4)[0:]' incomplete type appears to be causing ICE during
    gimplify_expr() due to 'is_gimple_val, fb_rvalue'. The ICE appears to be
fixed
    just by adjusting to 'is_gimple_lvalue, fb_lvalue'. Considering the use of
the
    affinity() clause, which should be specifying the location of a particular
    object in memory, this probably makes sense.

    gcc/ChangeLog:

            PR middle-end/103643

            * gimplify.c (gimplify_omp_affinity): Adjust gimplify_expr of
entire
            OMP_CLAUSE_DECL to use 'is_gimple_lvalue, fb_lvalue'

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/pr103643.f90: New test.