| Message ID | aa77cb08-5ab4-a837-0edb-5f356879a3c8@codethink.co.uk |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Hi Mark,
> Please find attached Steve Kargl's fix for PR93814.
The attached patch does not match the ChangeLog; it seems to
be for PR93484.
Regards
Thomas
Apologies, 2nd attempt: gcc/fortran/ChangeLog: Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/93814 * resolve.c (gfc_verify_binding_labels): Handle symbols with the subroutine attribute separately from symbols with the function attribute. gcc/testsuite/ChanheLog: Mark Eggleston <mark.eggleston@codethink.com> PR fortran/93814 * gfortran.dg/pr93814.f90: New test. OK to commit? On 22/03/2020 17:46, Thomas Koenig wrote: > Hi Mark, > >> Please find attached Steve Kargl's fix for PR93814. > > The attached patch does not match the ChangeLog; it seems to > be for PR93484. > > Regards > > Thomas >
**ping** On 23/03/2020 14:55, Mark Eggleston wrote: > Apologies, 2nd attempt: > > gcc/fortran/ChangeLog: > > Steven G. Kargl <kargl@gcc.gnu.org> > > PR fortran/93814 > * resolve.c (gfc_verify_binding_labels): Handle symbols with > the subroutine attribute separately from symbols with the > function attribute. > > gcc/testsuite/ChanheLog: > > Mark Eggleston <mark.eggleston@codethink.com> > > PR fortran/93814 > * gfortran.dg/pr93814.f90: New test. > > OK to commit? > > On 22/03/2020 17:46, Thomas Koenig wrote: >> Hi Mark, >> >>> Please find attached Steve Kargl's fix for PR93814. >> >> The attached patch does not match the ChangeLog; it seems to >> be for PR93484. >> >> Regards >> >> Thomas >>
Hi Mark,
the error message does not make sense – and I also currently
do not see why that example should be invalid.
Regarding the error message:
"uses the same global identifier"
In the test program (attached or PR) I do see one function "f"
and one entry "g" – and both "f" and "g" is only used once.
I also checked the F2018 standard and did not spot anything
which restricts this example.
Hence, I believe the test case is valid and, hence, the patch
does not solve the actual problem.
Cheers,
Tobias
On 3/23/20 3:55 PM, Mark Eggleston wrote:
> Apologies, 2nd attempt:
>
> gcc/fortran/ChangeLog:
>
> Steven G. Kargl <kargl@gcc.gnu.org>
>
> PR fortran/93814
> * resolve.c (gfc_verify_binding_labels): Handle symbols with
> the subroutine attribute separately from symbols with the
> function attribute.
>
> gcc/testsuite/ChanheLog:
>
> Mark Eggleston <mark.eggleston@codethink.com>
>
> PR fortran/93814
> * gfortran.dg/pr93814.f90: New test.
>
> OK to commit?
>
> On 22/03/2020 17:46, Thomas Koenig wrote:
>> Hi Mark,
>>
>>> Please find attached Steve Kargl's fix for PR93814.
>>
>> The attached patch does not match the ChangeLog; it seems to
>> be for PR93484.
>>
>> Regards
>>
>> Thomas
>>
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
From 4a3db68ce1fc8696b0108b4b0633c1f0959dac80 Mon Sep 17 00:00:00 2001
From: Mark Eggleston <markeggleston@gcc.gnu.org>
Date: Tue, 11 Feb 2020 08:35:02 +0000
Subject: [PATCH] fortran: ICE using undeclared symbol in array constructor
PR93484
Using undeclared symbol k in an expression in the following
array constructor results in an ICE:
print *, [real(x(k))]
If the call to the intrinsic is not in a constructor a no IMPLICIT
type error is reported and the ICE does not occur.
Matching on an expression instead of an initialisation express an
and not converting a MATCH_ERROR return value into MATCH_NO results
in the no IMPLICIT error and no ICE.
Note: Steven G. Kargl <kargl@gcc.gnu.org> is the author of the
changes except for the test cases.
gcc/fortran/ChangeLog:
PR fortran/93484
* match.c (gfc_match_type_spec): Replace gfc_match_init_expr with
gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR.
gcc/testsuite
PR fortran/93484
* gfortran.dg/pr93484_1.f90: New test.
* gfortran.dg/pr93484_2.f90: New test.
---
gcc/fortran/match.c | 4 ++--
gcc/testsuite/gfortran.dg/pr93484_1.f90 | 8 ++++++++
gcc/testsuite/gfortran.dg/pr93484_2.f90 | 8 ++++++++
3 files changed, 18 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr93484_1.f90
create mode 100644 gcc/testsuite/gfortran.dg/pr93484_2.f90
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index a74cb8c5c19..03adfca9bd9 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2222,9 +2222,9 @@ gfc_match_type_spec (gfc_typespec *ts)
found:
- m = gfc_match_init_expr (&e);
+ m = gfc_match_expr (&e);
if (m == MATCH_NO || m == MATCH_ERROR)
- return MATCH_NO;
+ return m;
/* If a comma appears, it is an intrinsic subprogram. */
gfc_gobble_whitespace ();
diff --git a/gcc/testsuite/gfortran.dg/pr93484_1.f90 b/gcc/testsuite/gfortran.dg/pr93484_1.f90
new file mode 100644
index 00000000000..3b6dbc9ad79
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93484_1.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+program p
+ implicit none
+ integer :: x(4) = [1,2,3,4]
+ print *, [real(x(k))] ! { dg-error "Symbol 'k' at .1. has no IMPLICIT type" }
+end
+
diff --git a/gcc/testsuite/gfortran.dg/pr93484_2.f90 b/gcc/testsuite/gfortran.dg/pr93484_2.f90
new file mode 100644
index 00000000000..4a7f4330ed9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93484_2.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+!
+program p
+ implicit none
+ integer, parameter :: x(4) = [1,2,3,4]
+ print *, [real(x(k))] ! { dg-error "Symbol 'k' at .1. has no IMPLICIT type" }
+end
+
--
2.11.0