[PATCH, committed] PR fortran/103286 - ICE in resolve_select, at fortran/resolve.c:8848
Committed to mainline as obvious after regtesting.
When issuing an error on an invalid range in a SELECT CASE statement
with a logical case expression, we need to be careful to use the
right locus information.
Thanks,
Harald
From 3b3c9932338650c9a402cf1bfbdf7dfc03e185e7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 16 Nov 2021 21:06:06 +0100
Subject: [PATCH] Fortran: avoid NULL pointer dereference on invalid range in
logical SELECT CASE
gcc/fortran/ChangeLog:
PR fortran/103286
* resolve.c (resolve_select): Choose appropriate range limit to
avoid NULL pointer dereference when generating error message.
gcc/testsuite/ChangeLog:
PR fortran/103286
* gfortran.dg/pr103286.f90: New test.
---
gcc/fortran/resolve.c | 3 ++-
gcc/testsuite/gfortran.dg/pr103286.f90 | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr103286.f90
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..f074a0ab3a1 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8846,7 +8846,8 @@ resolve_select (gfc_code *code, bool select_type)
|| cp->low != cp->high))
{
gfc_error ("Logical range in CASE statement at %L is not "
- "allowed", &cp->low->where);
+ "allowed",
+ cp->low ? &cp->low->where : &cp->high->where);
t = false;
break;
}
diff --git a/gcc/testsuite/gfortran.dg/pr103286.f90 b/gcc/testsuite/gfortran.dg/pr103286.f90
new file mode 100644
index 000..1c18b7136ce
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103286.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "std=gnu" }
+! PR fortran/103286 - ICE in resolve_select
+
+program p
+ select case (.true.) ! { dg-warning "Extension: Conversion" }
+ case (1_8)
+ case (:0)! { dg-error "Logical range in CASE statement" }
+ case (2:)! { dg-error "Logical range in CASE statement" }
+ end select
+end
--
2.26.2
Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]
Hi Bernhard,
I'm trying to understand your patch. What does it really try to solve?
PR88009 is closed and seems to have nothing to do with this.
Harald
Am 14.11.21 um 23:17 schrieb Bernhard Reutner-Fischer via Fortran:
Hi!
Amend fix for PR88009 to mark all these class components as artificial.
gcc/fortran/ChangeLog:
* class.c (gfc_build_class_symbol, generate_finalization_wrapper,
(gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool for
names. Mark internal symbols as artificial.
* decl.c (gfc_match_decl_type_spec, gfc_match_end): Fix
indentation.
(gfc_match_derived_decl): Fix indentation. Check extension level
before incrementing refs counter.
* parse.c (parse_derived): Fix style.
* resolve.c (resolve_global_procedure): Likewise.
* symbol.c (gfc_check_conflict): Do not ignore artificial symbols.
(gfc_add_flavor): Reorder condition, cheapest first.
(gfc_new_symbol, gfc_get_sym_tree,
generate_isocbinding_symbol): Fix style.
* trans-expr.c (gfc_trans_subcomponent_assign): Remove
restriction on !artificial.
* match.c (gfc_match_equivalence): Special-case CLASS_DATA for
warnings.
---
gfc_match_equivalence(), too, should not bail-out early on the first
error but should diagnose all errors. I.e. not goto cleanup but set
err=true and continue in order to diagnose all constraints of a
statement. Maybe Sandra or somebody else will eventually find time to
tweak that.
I think it also plugs a very minor leak of name in gfc_find_derived_vtab
so i also tagged it [PR68800]. At least that was the initial
motiviation to look at that spot.
We were doing
- name = xasprintf ("__vtab_%s", tname);
...
gfc_set_sym_referenced (vtab);
- name = xasprintf ("__vtype_%s", tname);
Bootstrapped and regtested without regressions on x86_64-unknown-linux.
Ok for trunk?
