From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CF14E3858433; Mon, 6 Nov 2023 15:26:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CF14E3858433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1699284381; bh=IUgpkxj3UbXnx1gTXYQ5zDSt+cy6j+R1Mb6nSEHiUlo=; h=From:To:Subject:Date:From; b=h7KbGkrCxJOt0p5X3yon8SJJB29AMa93LRTJOv6pEAi6dp8LD/zfpK20CXvXTxZ9d 6Bud9xNGnTdmdIFbY/pS9Y9WUpScOkKuBeBfnSvV1wGJHxGM1T4e1PVzOsqBBObVfR 8Ft1r5xMS3rDdFOx9Vo1gMokorNd5VpTejGm0kTU= From: "trnka at scm dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/112407] New: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab Date: Mon, 06 Nov 2023 15:26:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trnka at scm dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112407 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=3D56515&action=3Dedit reproducer with dependencies Following up on comment 7 in PR109684. This seems to be another issue uncov= ered by the finalization overhaul: commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee Author: Paul Thomas Date: Sat Mar 18 07:56:23 2023 +0000 Fortran: Fix bugs and missing features in finalization [PR37336] 2023-03-18 Paul Thomas 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=3D0, gmsgid=3D0x1e55748 "Non-RECURSIVE procedure %qs at %L is possibly calli= ng 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 >=3D 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->whe= re in resolve_structure_cons both look like the bogus locus causing the assert: (gdb) p cons->where $6 =3D {nextc =3D 0x0, lb =3D 0x0} (gdb) p cons->expr->where $8 =3D {nextc =3D 0x0, lb =3D 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 =3D=3D BT_CLASS || sym->ts.type =3D=3D BT_DERIVED)) { gfc_expr *final_expr =3D 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_finalizabl= e() on the affected module that directly triggers the bug. Two TBPs in the affe= cted 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 argume= nts 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.f9= 0. 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) a= nd 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 abl= e 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 sourc= es 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, perha= ps we can then design a synthetic testcase that could then be included in the = GCC regression test suite.=