[Bug fortran/108450] New: [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380

[Bug fortran/108450] New: [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380

[gscfq@t-online.de]

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

            Bug ID: 108450
           Summary: [12/13 Regression] ICE in sort_actual, at
                    fortran/intrinsic.cc:4380
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

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

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.3
           Priority|P3                          |P4

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-01-19
            Summary|[12/13 Regression] ICE in   |[12/13 Regression] ICE in
                   |sort_actual, at             |sort_actual, at
                   |fortran/intrinsic.cc:4380   |fortran/intrinsic.cc:4380
                   |                            |since
                   |                            |r12-5793-g689407ef916503b2
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-5793-g689407ef916503b2.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
Taking, patch submitted: 
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610834.html

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for gcc-13.1 and gcc-12.3.
Closing.