From: Paul Richard Thomas <paul.richard.thomas@gmail.com>
To: gfortran@gcc.gnu.org, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [Patch, fortran] PR103471 - [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114
Date: Fri, 19 Apr 2024 17:52:53 +0100 [thread overview]
Message-ID: <CAGkQGiJv6oqU8_PWiWq-U4BpyDrk8nhvqtm8PC56cQVZWJQpxw@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 981 bytes --]
Hi All,
This is a more or less obvious patch. The action is in resolve.cc. The
chunk in symbol.cc is a tidy up of a diagnostic marker to distinguish where
the 'no IMPLICIT type' error was coming from and the chunk in trans-decl.cc
follows from discussion with Harald on the PR.
Regtests fine. OK for mainline and backporting in a couple of weeks?
Paul
Fortran: Detect 'no implicit type' error in right place [PR103471]
2024-04-19 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/103471
* resolve.cc (gfc_resolve_index_1): Block index expressions of
unknown type from being converted to default integer, avoiding
the fatal error in trans-decl.cc.
* symbol.cc (gfc_set_default_type): Remove '(symbol)' from the
'no IMPLICIT type' error message.
* trans-decl.cc (gfc_get_symbol_decl): Change fatal error locus
to that of the symbol declaration.
(gfc_trans_deferred_vars): Remove two trailing tabs.
gcc/testsuite/
PR fortran/103471
* gfortran.dg/pr103471.f90: New test.
[-- Attachment #2: submit.diff --]
[-- Type: text/x-patch, Size: 2767 bytes --]
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 6b3e5ba4fcb..9b7fabd3707 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5001,7 +5001,8 @@ gfc_resolve_index_1 (gfc_expr *index, int check_scalar,
if ((index->ts.kind != gfc_index_integer_kind
&& force_index_integer_kind)
- || index->ts.type != BT_INTEGER)
+ || (index->ts.type != BT_INTEGER
+ && index->ts.type != BT_UNKNOWN))
{
gfc_clear_ts (&ts);
ts.type = BT_INTEGER;
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 3a3b6de5cec..8f7deac1d1e 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -320,7 +320,7 @@ gfc_set_default_type (gfc_symbol *sym, int error_flag, gfc_namespace *ns)
"; did you mean %qs?",
sym->name, &sym->declared_at, guessed);
else
- gfc_error ("Symbol %qs at %L has no IMPLICIT type(symbol)",
+ gfc_error ("Symbol %qs at %L has no IMPLICIT type",
sym->name, &sym->declared_at);
sym->attr.untyped = 1; /* Ensure we only give an error once. */
}
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index e160c5c98c1..301439baaf5 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1797,7 +1797,8 @@ gfc_get_symbol_decl (gfc_symbol * sym)
}
if (sym->ts.type == BT_UNKNOWN)
- gfc_fatal_error ("%s at %C has no default type", sym->name);
+ gfc_fatal_error ("%s at %L has no default type", sym->name,
+ &sym->declared_at);
if (sym->attr.intrinsic)
gfc_internal_error ("intrinsic variable which isn't a procedure");
@@ -5214,8 +5215,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
tree tmp = lookup_attribute ("omp allocate",
DECL_ATTRIBUTES (n->sym->backend_decl));
tmp = TREE_VALUE (tmp);
- TREE_PURPOSE (tmp) = se.expr;
- TREE_VALUE (tmp) = align;
+ TREE_PURPOSE (tmp) = se.expr;
+ TREE_VALUE (tmp) = align;
TREE_PURPOSE (TREE_CHAIN (tmp)) = init_stmtlist;
TREE_VALUE (TREE_CHAIN (tmp)) = cleanup_stmtlist;
}
diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90 b/gcc/testsuite/gfortran.dg/pr93484.f90
new file mode 100644
index 00000000000..4dcad47e8da
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103471.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! Test the fix for PR103471 in which, rather than giving a "no IMPLICIT type"
+! message, gfortran took to ICEing. The fuzzy symbol check for 'kk' demonstrates
+! that the error is being detected in the right place.
+!
+! Contributed by Gerhard Steinmetz <gscfq@t-online.de>
+!
+program p
+ implicit none
+ integer, parameter :: x(4) = [1,2,3,4]
+ integer :: kk
+ print *, [real(x(k))] ! { dg-error "has no IMPLICIT type; did you mean .kk.\\?" }
+end
next reply other threads:[~2024-04-19 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 16:52 Paul Richard Thomas [this message]
2024-04-19 18:33 ` Harald Anlauf
2024-04-19 18:33 ` Harald Anlauf
2024-04-20 7:54 ` Paul Richard Thomas
2024-04-20 13:05 ` Harald Anlauf
2024-04-20 13:05 ` Harald Anlauf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGkQGiJv6oqU8_PWiWq-U4BpyDrk8nhvqtm8PC56cQVZWJQpxw@mail.gmail.com \
--to=paul.richard.thomas@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gfortran@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).