[PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Mark Eggleston]

[-- 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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Steve Kargl]

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 ();

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Mark Eggleston]

**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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Thomas Koenig]

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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Mark Eggleston]

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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

[Tobias Burnus]

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.)