[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:85a3442c85aedb00c59e986f16cccbb8ec60d777 commit r12-6268-g85a3442c85aedb00c59e986f16cccbb8ec60d777 Author: Sandra Loosemore Date: Tue Jan 4 18:18:13 2022 -0800 Fortran: Fix ICE caused by missing error for untyped symbol [PR103258] The bit on a symbol to mark that it had already been diagnosed as lacking a type was getting set even when the error was suppressed or discarded, specifically when doing early resolution on a character length expression to see if it can be constant-folded. Explicitly suppress errors before doing that, then check whether they are suppressed before setting the bit. 2022-01-04 Sandra Loosemore PR fortran/103258 gcc/fortran/ * decl.c (gfc_match_char_spec): Suppress errors around call to gfc_reduce_init_expr. * error.c (gfc_query_suppress_errors): New. * gfortran.h (gfc_query_suppress_errors): Declare. * symbol.c (gfc_set_default_type): Check gfc_query_suppress_errors. gcc/testsuite/ * gfortran.dg/pr103258.f90: New.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #5 from sandra at gcc dot gnu.org --- The previous hacky patch had some testsuite regressions. I've posted a less hacky one that doesn't trigger new failures here: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587632.html
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #4 from sandra at gcc dot gnu.org --- Created attachment 51980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51980=edit hacky patch Attached patch has not been regression tested, but it does seem to fix the original testcase, which now produces: $ gfortran -c pr103258.f90 pr103258.f90:3:13: 3 | character(n+m) :: c | 1 Error: Symbol 'm' at (1) has no IMPLICIT type pr103258.f90:1:14: 1 | subroutine s(n) | 1 Error: Symbol 'n' at (1) has no IMPLICIT type
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #3 from sandra at gcc dot gnu.org --- This looks like an existing bug in error checking that was exposed by my patch to do... more error checking. :-S The problem is that gfc_set_default_type in symbol.c is setting sym->attr.untyped even when errors are suppressed or buffered and discarded during parsing. Since it's marked as having already been diagnosed, we aren't giving an error in subsequent calls where errors are *not* being suppressed or discarded, and thus compilation continues as if nothing were wrong, until it falls over. Previously we were resolving only the second operand "m" in the "(n+m)" expression in a situation where errors are buffered in the parsing stage, leaving "n" without the attr.untyped flag set so that it was being diagnosed later during the actual resolve phase of processing. Now it is setting that flag on both "n" and "m" so neither ever gives a real error. I've got a hacky patch to avoid setting sym->attr.untyped when a real error might not be given, but I'm not sure if it's the right solution. Maybe a better solution would be to emit the diagnostic somewhere other than gfc_set_default_type, at a known point in the processing where it'll only happen once?
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I'll take a look when I have time, but I'm deep in another bug right now so it may be a few days. Anybody else feel free to grab it meanwhile...
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P4
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||sandra at codesourcery dot com Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_typenode_for_spec, at |gfc_typenode_for_spec, at |fortran/trans-types.c:1114 |fortran/trans-types.c:1114 ||since ||r12-4979-gee11be7f2d788e60 Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-16 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-4979-gee11be7f2d788e60.
