[Bug fortran/112407] New: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

["trnka at scm dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 112407
           Summary: [13 Regression] Fix for PR37336 triggers an ICE in
                    gfc_format_decoder while constructing a vtab
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trnka at scm dot com
  Target Milestone: ---

Created attachment 56515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56515&action=edit
reproducer with dependencies

Following up on comment 7 in PR109684. This seems to be another issue uncovered
by the finalization overhaul:

commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Mar 18 07:56:23 2023 +0000

    Fortran: Fix bugs and missing features in finalization [PR37336]

    2023-03-18  Paul Thomas  <pault@gcc.gnu.org>

The attached test triggers an assert in gfc_format_decoder, at
fortran/error.cc:1078 (on current 13 branch):

0x65cce5 gfc_format_decoder
        gcc/fortran/error.cc:1078
0x1b12ed9 pp_format(pretty_printer*, text_info*)
        gcc/pretty-print.cc:1475
0x1b030d1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
        gcc/diagnostic.cc:1592
0x6e0127 gfc_report_diagnostic
        gcc/fortran/error.cc:890
0x6e0127 gfc_warning
        gcc/fortran/error.cc:923
0x6e07e6 gfc_warning(int, char const*, ...)
        gcc/fortran/error.cc:954
0x765d5e resolve_procedure_expression
        gcc/fortran/resolve.cc:1956
0x765d5e resolve_variable
        gcc/fortran/resolve.cc:6066
0x765d5e gfc_resolve_expr(gfc_expr*)
        gcc/fortran/resolve.cc:7302
0x7635c9 gfc_resolve_expr(gfc_expr*)
        gcc/fortran/resolve.cc:7267
0x7635c9 resolve_structure_cons
        gcc/fortran/resolve.cc:1341
0x774521 resolve_values
        gcc/fortran/resolve.cc:12802
0x78afd2 do_traverse_symtree
        gcc/fortran/symbol.cc:4190
0x76ac7d resolve_types
        gcc/fortran/resolve.cc:17941
0x771efc gfc_resolve(gfc_namespace*)
        gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
        gcc/fortran/resolve.cc:16602
0x78afd2 do_traverse_symtree
        gcc/fortran/symbol.cc:4190
0x76ab9e resolve_types
        gcc/fortran/resolve.cc:17920
0x771efc gfc_resolve(gfc_namespace*)
        gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
        gcc/fortran/resolve.cc:16602

This assert is hit while printing the following warning:

#0  gfc_warning (opt=0,
    gmsgid=0x1e55748 "Non-RECURSIVE procedure %qs at %L is possibly calling
itself recursively.  Declare it RECURSIVE or use %<-frecursive%>")

In particular, the following line in gfc_format_decoder is failing:

gcc_assert (loc->nextc - loc->lb->line >= 0);

That's because both loc->nextc and loc->lb are 0 here. Walking up the stack, I
have found that this all happens while resolving the structure constructor for
__vtab_ftldynarrayintmodule_Ftldynarrayint. cons->where and cons->expr->where
in resolve_structure_cons both look like the bogus locus causing the assert:

(gdb) p cons->where
$6 = {nextc = 0x0, lb = 0x0}
(gdb) p cons->expr->where
$8 = {nextc = 0x0, lb = 0x0}

Picking the massive commit mentioned above apart into small chunks and
reverting them one by one, I have narrowed the triggering change down to the
following addition to resolve_symbol():

  if (!sym->attr.referenced
      && (sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED))
    {
      gfc_expr *final_expr = gfc_lval_expr_from_sym (sym);
      if (gfc_is_finalizable (final_expr->ts.u.derived, NULL))
       gfc_set_sym_referenced (sym);
      gfc_free_expr (final_expr);
    }

Specifically, it's the call to gfc_find_derived_vtab() in gfc_is_finalizable()
on the affected module that directly triggers the bug. Two TBPs in the affected
type are directly involved in triggering the assert. Applying the attached hack
works around the issue (by skipping the call to gfc_find_derived_vtab() for the
two affected routines.

FWIW, both affected routines (NewCopyOther and AssignOther) have two arguments
like this:

   subroutine NewCopyOther(self, other)
      class(ftlDynArrayInt), intent(out) :: self
      type(ftlDynArrayInt),  intent(in)  :: other

   impure elemental subroutine AssignOther(self, other)
      class(ftlDynArrayInt), intent(inout) :: self
      type(ftlDynArrayInt),  intent(in)    :: other

It's always the "other" argument which triggers this, the "self" one never hits
the bit in resolve_symbol() mentioned above. Changing "other" to
class(ftlDynArrayInt) also makes the issue go away.

To reproduce this, unpack the attached tarball (containing the testcase and
three dependency .mod files) and run gfortran -c test-vtab-construct-ice.f90.
The ftlDynArrayInt type hitting the issue is pulled in by the
ChemicalSystemModule, which seems to be a key ingredient. It's a really big
module with dozens of dependencies (so I can't feasibly provide them all) and
the chemicalsystemmodule.mod is about a megabyte uncompressed. It looks like
the bug depends on the size/layout of this big module, because I wasn't able to
reduce it without making the issue go away. However, while removing any
component from the ChemicalSystemType made the issue disappear, stuffing the
type with a few integer components then made the issue come back again.

It also doesn't seem to be possible to reduce test-vtab-construct-ice.f90
further. Even the order of the subroutines seems to matter, putting A() last
makes the issue go away.

I'm happy to assist with debugging this, although I can't provide the sources
for all the modules involved as this involves a significant part of our
proprietary codebase. If you can help me narrow down the cause a bit, perhaps
we can then design a synthetic testcase that could then be included in the GCC
regression test suite.