public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258]
@ 2022-01-05  3:21 Sandra Loosemore
  2022-01-05 12:44 ` Paul Richard Thomas
  0 siblings, 1 reply; 2+ messages in thread
From: Sandra Loosemore @ 2022-01-05  3:21 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

This patch fixes an ICE that appeared after I checked in my patch for 
PR101337 back in November, which made the resolve phase try harder to 
check all operands/arguments for errors instead of giving up after the 
first one, but it's actually a bug that existed before that and was only 
revealed by that earlier patch.

The problem is that the parse phase is doing early resolution to try to 
constant-fold a character length expression.  It's throwing away the 
error(s) if it fails, but in the test case for this issue it was leaving 
behind some state indicating that the error had already been diagnosed 
so it wasn't getting caught again during the "real" resolution phase either.

Every bit of code touched by this seems kind of hacky to me -- the 
different mechanisms for suppressing/ignoring errors, the magic bit in 
the symbol attributes, the part that tries to constant-fold an 
expression that might not actually be a constant, etc.  But, this is the 
least hacky fix I could come up with.  :-P  It fixes the test case from 
the issue and does not cause any regressions elsewhere in the gfortran 
testsuite.

OK to check in?

-Sandra

[-- Attachment #2: pr103258.patch --]
[-- Type: text/x-patch, Size: 3548 bytes --]

commit ea7deef7dad4239435374884713a187ae8faa4eb
Author: Sandra Loosemore <sandra@codesourcery.com>
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  <sandra@codesourcery.com>
    
    	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.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4e510cc..c846923 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3609,7 +3609,9 @@ done:
 	  gfc_current_ns = gfc_get_namespace (NULL, 0);
 
 	  e = gfc_copy_expr (len);
+	  gfc_push_suppress_errors ();
 	  gfc_reduce_init_expr (e);
+	  gfc_pop_suppress_errors ();
 	  if (e->expr_type == EXPR_CONSTANT)
 	    {
 	      gfc_replace_expr (len, e);
diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index be2eb93..e95c083 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -83,6 +83,15 @@ gfc_pop_suppress_errors (void)
 }
 
 
+/* Query whether errors are suppressed.  */
+
+bool
+gfc_query_suppress_errors (void)
+{
+  return suppress_errors > 0;
+}
+
+
 /* Determine terminal width (for trimming source lines in output).  */
 
 static int
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d01a9dc..3b791a4 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1083,6 +1083,7 @@ typedef struct
 
 void gfc_push_suppress_errors (void);
 void gfc_pop_suppress_errors (void);
+bool gfc_query_suppress_errors (void);
 
 
 /* Character length structures hold the expression that gives the
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 0385595..1a4b022 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -299,7 +299,7 @@ gfc_set_default_type (gfc_symbol *sym, int error_flag, gfc_namespace *ns)
 
   if (ts->type == BT_UNKNOWN)
     {
-      if (error_flag && !sym->attr.untyped)
+      if (error_flag && !sym->attr.untyped && !gfc_query_suppress_errors ())
 	{
 	  const char *guessed = lookup_symbol_fuzzy (sym->name, sym);
 	  if (guessed)
diff --git a/gcc/testsuite/gfortran.dg/pr103258.f90 b/gcc/testsuite/gfortran.dg/pr103258.f90
new file mode 100644
index 0000000..4521fcd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103258.f90
@@ -0,0 +1,14 @@
+! { dg-do compile}
+! { dg-additional-options "-Wno-pedantic" }
+!
+! Test from PR103258.  This used to ICE due to incorrectly marking the
+! no-implicit-type error for n and m in the character length expression
+! as already diagnosed during early resolution, when in fact errors are
+! ignored in that parsing context.  We now expect the errors to be diagnosed
+! at the point of the first use of each symbol.
+
+subroutine s(n) ! { dg-error "Symbol 'n' .*has no IMPLICIT type" }
+implicit none
+character(n+m) :: c ! { dg-error "Symbol 'm' .*has no IMPLICIT type" }
+entry e(m)
+end

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258]
  2022-01-05  3:21 [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258] Sandra Loosemore
@ 2022-01-05 12:44 ` Paul Richard Thomas
  0 siblings, 0 replies; 2+ messages in thread
From: Paul Richard Thomas @ 2022-01-05 12:44 UTC (permalink / raw)
  To: Sandra Loosemore; +Cc: fortran, gcc-patches

Hi Sandra,

That's a good shout to query suppress_errors. The patch is OK by me.

Thanks

Paul


On Wed, 5 Jan 2022 at 03:21, Sandra Loosemore <sandra@codesourcery.com>
wrote:

> This patch fixes an ICE that appeared after I checked in my patch for
> PR101337 back in November, which made the resolve phase try harder to
> check all operands/arguments for errors instead of giving up after the
> first one, but it's actually a bug that existed before that and was only
> revealed by that earlier patch.
>
> The problem is that the parse phase is doing early resolution to try to
> constant-fold a character length expression.  It's throwing away the
> error(s) if it fails, but in the test case for this issue it was leaving
> behind some state indicating that the error had already been diagnosed
> so it wasn't getting caught again during the "real" resolution phase
> either.
>
> Every bit of code touched by this seems kind of hacky to me -- the
> different mechanisms for suppressing/ignoring errors, the magic bit in
> the symbol attributes, the part that tries to constant-fold an
> expression that might not actually be a constant, etc.  But, this is the
> least hacky fix I could come up with.  :-P  It fixes the test case from
> the issue and does not cause any regressions elsewhere in the gfortran
> testsuite.
>
> OK to check in?
>
> -Sandra
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-01-05 12:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-05  3:21 [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258] Sandra Loosemore
2022-01-05 12:44 ` Paul Richard Thomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).