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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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  <[hidden email]>
>
>     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 ();
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Tobias Burnus-3
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.)