* [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
@ 2020-02-11 12:10 Mark Eggleston
2020-02-11 15:23 ` Steve Kargl
0 siblings, 1 reply; 6+ messages in thread
From: Mark Eggleston @ 2020-02-11 12:10 UTC (permalink / raw)
To: gcc-patches, fortran
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
Please find attached a patch for PR93484. The original author is Steve
Kargl. I have added the test cases.
OK for master?
running make produces the following for check-fortran gcc-8 and gcc-9
but not master:
XPASS: gfortran.dg/typebound_call_22.f03Â Â -O scan-tree-dump-times
optimized "base \\(\\);" 1
What do I need to do to backport to gcc 8 and gcc 9 branches?
The changelogs:
gcc/fortran/ChangeLog
   Steven G. Kargl <kargl@gcc.gnu.org>
   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/ChangeLog
   Mark Eggleston <mark.eggleston@codethink.com>
   PR fortran/93484
   * gfortran/pr93484_1.f90: New test.
   * gfortran/pr93484_2.f90: New test.
--
https://www.codethink.co.uk/privacy.html
[-- Attachment #2: 0001-fortran-ICE-using-undeclared-symbol-in-array-constru.patch --]
[-- Type: text/x-patch, Size: 2644 bytes --]
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/pr93484_1.f90: New test.
* gfortran/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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
2020-02-11 12:10 [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484 Mark Eggleston
@ 2020-02-11 15:23 ` Steve Kargl
2020-02-24 14:19 ` Mark Eggleston
0 siblings, 1 reply; 6+ messages in thread
From: Steve Kargl @ 2020-02-11 15:23 UTC (permalink / raw)
To: Mark Eggleston; +Cc: gcc-patches, fortran
On Tue, Feb 11, 2020 at 12:10:41PM +0000, Mark Eggleston wrote:
> Please find attached a patch for PR93484. The original author is Steve
> Kargl. I have added the test cases.
>
> OK for master?
I obviously think the patch is ok, but I'll let someone else review it.
>    Steven G. Kargl <kargl@gcc.gnu.org>
>
> Â Â Â 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.
>
> 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;
Might need
gfc_reduce_init_expr (e);
here. The kind type parameter should be a constant expression.
> /* If a comma appears, it is an intrinsic subprogram. */
> gfc_gobble_whitespace ();
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
2020-02-11 15:23 ` Steve Kargl
@ 2020-02-24 14:19 ` Mark Eggleston
2020-02-24 14:34 ` Thomas Koenig
0 siblings, 1 reply; 6+ messages in thread
From: Mark Eggleston @ 2020-02-24 14:19 UTC (permalink / raw)
To: sgk; +Cc: gcc-patches, fortran
**ping**
The following was a reply to
https://gcc.gnu.org/ml/fortran/2020-02/msg00042.html
see response below. OK to commit?
On 11/02/2020 15:23, Steve Kargl wrote:
> On Tue, Feb 11, 2020 at 12:10:41PM +0000, Mark Eggleston wrote:
>> Please find attached a patch for PR93484. The original author is Steve
>> Kargl. I have added the test cases.
>>
>> OK for master?
> I obviously think the patch is ok, but I'll let someone else review it.
>
>>    Steven G. Kargl <kargl@gcc.gnu.org>
>>
>> Â Â Â 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.
>>
>> 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;
> Might need
>
> gfc_reduce_init_expr (e);
>
> here. The kind type parameter should be a constant expression.
Not needed. I've also checked use of the kind argument, it is evidently
checked elsewhere: if k is allowed to be implicitly declared and is used
as the kind argument errors are reported that it is not a constant, if
implicit declaration is not allowed a "has no IMPLICIT type" error is
produced.
>
>> /* If a comma appears, it is an intrinsic subprogram. */
>> gfc_gobble_whitespace ();
--
https://www.codethink.co.uk/privacy.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
2020-02-24 14:19 ` Mark Eggleston
@ 2020-02-24 14:34 ` Thomas Koenig
2020-02-24 14:50 ` Mark Eggleston
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Koenig @ 2020-02-24 14:34 UTC (permalink / raw)
To: Mark Eggleston, sgk; +Cc: gcc-patches, fortran
Hi Mark,
>> Might need
>>
>> Â Â Â Â Â Â Â Â gfc_reduce_init_expr (e);
>>
>> here. The kind type parameter should be a constant expression.
>
> Not needed. I've also checked use of the kind argument, it is evidently
> checked elsewhere: if k is allowed to be implicitly declared and is used
> as the kind argument errors are reported that it is not a constant, if
> implicit declaration is not allowed a "has no IMPLICIT type" error is
> produced.
Is there a test case that covers this already? OK if such a test
case exists, also OK with such a test case (or if looking for it
is too bother :-)
Regards
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
2020-02-24 14:34 ` Thomas Koenig
@ 2020-02-24 14:50 ` Mark Eggleston
2020-02-24 15:01 ` Tobias Burnus
0 siblings, 1 reply; 6+ messages in thread
From: Mark Eggleston @ 2020-02-24 14:50 UTC (permalink / raw)
To: Thomas Koenig, sgk; +Cc: gcc-patches, fortran
On 24/02/2020 14:34, Thomas Koenig wrote:
> Hi Mark,
>
>>> Might need
>>>
>>> Â Â Â Â Â Â Â Â gfc_reduce_init_expr (e);
>>>
>>> here. The kind type parameter should be a constant expression.
>>
>> Not needed. I've also checked use of the kind argument, it is
>> evidently checked elsewhere: if k is allowed to be implicitly
>> declared and is used as the kind argument errors are reported that it
>> is not a constant, if implicit declaration is not allowed a "has no
>> IMPLICIT type" error is produced.
>
> Is there a test case that covers this already? OK if such a test
> case exists, also OK with such a test case (or if looking for it
> is too bother :-)
I've had a quick look and there doesn't appear to be a test for using a
non-constant for kind arguments. I think a proper set of tests for
invalid kind arguments that covers declarations and intrinsic arguments
should be added that is separate from this patch. Should that be done
while we're in stage 4 or should it wait for stage 1?
In the meantime I'll commit this patch either today or tomorrow.
>
> Regards
>
> Â Â Â Â Thomas
>
--
https://www.codethink.co.uk/privacy.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484
2020-02-24 14:50 ` Mark Eggleston
@ 2020-02-24 15:01 ` Tobias Burnus
0 siblings, 0 replies; 6+ messages in thread
From: Tobias Burnus @ 2020-02-24 15:01 UTC (permalink / raw)
To: Mark Eggleston, Thomas Koenig, sgk; +Cc: gcc-patches, fortran
On 2/24/20 3:50 PM, Mark Eggleston wrote:
> I've had a quick look and there doesn't appear to be a test for using
> a non-constant for kind arguments. I think a proper set of tests for
> invalid kind arguments that covers declarations and intrinsic
> arguments should be added that is separate from this patch. Should
> that be done while we're in stage 4 or should it wait for stage 1?
Test cases can always go in* â and usually having them earlier is better
than later. Besides, they cannot get forgotten if done now â and you
already have a stub. If we find bugs, we can still consider whether we
want to have them fixed now (Stage 4) or later (GCC 11 Stage 1 +
possibly backported).
Tobias
*Well, kind of. Some "dg-" syntax errors can break the testsuite â and
the release manager do not like any commit when the branch is "frozen".
(Directly before a release; approx. 1â3 days freeze; used to check that
everything builds fine before actually tagging a release.)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-24 15:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-11 12:10 [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484 Mark Eggleston
2020-02-11 15:23 ` Steve Kargl
2020-02-24 14:19 ` Mark Eggleston
2020-02-24 14:34 ` Thomas Koenig
2020-02-24 14:50 ` Mark Eggleston
2020-02-24 15:01 ` Tobias Burnus
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).