Started between 20211128 and 20211205 : $ cat z1.f90 program p integer :: a(8) = 0 integer :: l integer :: n !$omp atomic n = maxloc(a, mask=l) end $ cat z2.f90 program p integer :: a(8) = 0 logical :: l integer :: n(1) !$omp atomic n = maxloc(a, mask=l) end $ gfortran-13-20230115 -c z2.f90 -fopenmp z2.f90:6:3: 6 | n = maxloc(a, mask=l) | 1 Error: !$OMP ATOMIC statement must set a scalar variable of intrinsic type at (1) $ gfortran-13-20230115 -c z1.f90 -fopenmp z1.f90:6:22: 6 | n = maxloc(a, mask=l) | 1 Error: 'mask' argument of 'maxloc' intrinsic at (1) must be LOGICAL f951: internal compiler error: Segmentation fault 0xf8734f crash_signal ../../gcc/toplev.cc:314 0x84f083 sort_actual ../../gcc/fortran/intrinsic.cc:4380 0x84f2d4 check_specific ../../gcc/fortran/intrinsic.cc:4774 0x8574c4 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:5042 0x8aeb18 resolve_unknown_f ../../gcc/fortran/resolve.cc:2990 0x8aeb18 resolve_function ../../gcc/fortran/resolve.cc:3347 0x8aeb18 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7195 0x8806a4 resolve_omp_atomic ../../gcc/fortran/openmp.cc:8699 0x88de6c gfc_resolve_omp_directive(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.cc:10190 0x8b48ab gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12444 0x8b69e7 resolve_codes ../../gcc/fortran/resolve.cc:17629 0x8b6aae gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17664 0x89e844 resolve_all_program_units ../../gcc/fortran/parse.cc:6656 0x89e844 gfc_parse_file() ../../gcc/fortran/parse.cc:6912 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
Started with r12-5793-g689407ef916503b2.
Interestingly, it is resolved twice. First for: (gdb) p gfc_debug_expr(e) maxloc[((p:a) (mask = p:l))] via resolve_all_program_units → gfc_resolve → gfc_resolve → resolve_codes → gfc_resolve_code → gfc_resolve_blocks → gfc_resolve_code → gfc_resolve_expr And then via: ... → resolve_omp_atomic → gfc_resolve_expr The problem is that in the latter case, the 'e' is now: maxloc[((p:a(FULL)) (mask = p:l) (.false.))] and the unprefixed .false. seems to cause the problems. The intrinsic uses: RESULT = MAXLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK]) RESULT = MAXLOC(ARRAY [, MASK] [,KIND] [,BACK]) During the first call to check_specific, maxloc[((p:a(FULL)) (mask = p:l))] is turned into maxloc[((p:a(FULL)) ((arg not-present)) (mask = p:l) ((arg not-present)) ((arg not-present)))] via 4774 if (!sort_actual (specific->name, ap, specific->formal, &expr->where)) The null-args are later removed via 'remove_nullargs (ap);' * * * Thus, it looks as if resolving the RHS expression twice is wrong.
Taking, patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610834.html
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>: https://gcc.gnu.org/g:2e32a12c04c72f692a7bd119fd3e4e5b74392c9d commit r13-5486-g2e32a12c04c72f692a7bd119fd3e4e5b74392c9d Author: Mikael Morin <mikael@gcc.gnu.org> Date: Sun Jan 29 21:57:24 2023 +0100 fortran: Set name for *LOC default BACK argument [PR108450] This change fixes an ICE caused by the double resolution of MINLOC, MAXLOC and FINDLOC expressions which get a default value for the BACK argument at resolution time. That argument is added without name, and argument reordering code is not prepared to handle unnamed arguments coming after named ones, so the second resolution causes a NULL pointer dereference. The problem is fixed by explicitly setting the argument name. PR fortran/108450 gcc/fortran/ChangeLog: * check.cc (gfc_check_minloc_maxloc): Explicitly set argument name. (gfc_check_findloc): Ditto. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/minmaxloc_1.f90: New test.
The releases/gcc-12 branch has been updated by Mikael Morin <mikael@gcc.gnu.org>: https://gcc.gnu.org/g:32502d82a5b54ca5b8e524df9fcad851727dc54a commit r12-9108-g32502d82a5b54ca5b8e524df9fcad851727dc54a Author: Mikael Morin <mikael@gcc.gnu.org> Date: Sun Jan 29 21:57:24 2023 +0100 fortran: Set name for *LOC default BACK argument [PR108450] This change fixes an ICE caused by the double resolution of MINLOC, MAXLOC and FINDLOC expressions which get a default value for the BACK argument at resolution time. That argument is added without name, and argument reordering code is not prepared to handle unnamed arguments coming after named ones, so the second resolution causes a NULL pointer dereference. The problem is fixed by explicitly setting the argument name. PR fortran/108450 gcc/fortran/ChangeLog: * check.cc (gfc_check_minloc_maxloc): Explicitly set argument name. (gfc_check_findloc): Ditto. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/minmaxloc_1.f90: New test. (cherry picked from commit 2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)
Fixed for gcc-13.1 and gcc-12.3. Closing.