[PATCH] PR fortran/82049 -- resolve a charlen if possible

[PATCH] PR fortran/82049 -- resolve a charlen if possible

[Steve Kargl]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

The attached patch fixes PR fortran/82049.  Prior to this
patch, gfortran was fouling up the resolution of the charlen
expression in the testcase.  The immediately tries to resolve
the length while parsing the type-spec.

While here, I've introduced an optimization that causes
gfc_match_type_spec() to return early if the gfortran isn't
going to be getting a type-spec.  This is done be peeking
at the next character, if it is in [a-z], the we don't have
a type spec.  OK to commit?


2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/82049
	* match.c (gfc_match_type_spec): If the charlen is non-NULL, then
	try to resolve it.  While here return early if possible.

2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/82049
	* gfortran.dg/assumed_charlen_parameter.f90: New test.


-- 
Steve

[-- Attachment #2: pr82049.diff --]
[-- Type: text/x-diff, Size: 1526 bytes --]

Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c	(revision 257391)
+++ gcc/fortran/match.c	(working copy)
@@ -2054,11 +2054,17 @@ gfc_match_type_spec (gfc_typespec *ts)
 {
   match m;
   locus old_locus;
-  char name[GFC_MAX_SYMBOL_LEN + 1];
+  char c, name[GFC_MAX_SYMBOL_LEN + 1];
 
   gfc_clear_ts (ts);
   gfc_gobble_whitespace ();
   old_locus = gfc_current_locus;
+
+  /* If c isn't [a-z], then return immediately.  */
+  c = gfc_peek_ascii_char ();
+  if (!ISALPHA(c))
+    return MATCH_NO;
+
   type_param_spec_list = NULL;
 
   if (match_derived_type_spec (ts) == MATCH_YES)
@@ -2099,6 +2105,8 @@ gfc_match_type_spec (gfc_typespec *ts)
       ts->type = BT_CHARACTER;
 
       m = gfc_match_char_spec (ts);
+      if (ts->u.cl && ts->u.cl->length)
+	gfc_resolve_expr (ts->u.cl->length);
 
       if (m == MATCH_NO)
 	m = MATCH_YES;
Index: gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90
===================================================================
--- gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/82049
+! Original code contributed by John Harper <john dot harper at vuw dot ac dot nz>
+program ice ! f2003
+  implicit none
+  character(*), parameter:: a = 'ice', b = '*'
+  character(*), parameter:: c(2) = [character(len(a)) :: a, b]
+  print "(2A4)",adjustr(c)
+end program ice

Re: [PATCH] PR fortran/82049 -- resolve a charlen if possible

[Paul Richard Thomas]

Hi Steve,

That's OK for trunk and, if you are possessed of the intestinal
fortitude, 6- and 7-branches.

Thanks

Paul


On 7 February 2018 at 02:17, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> The attached patch fixes PR fortran/82049.  Prior to this
> patch, gfortran was fouling up the resolution of the charlen
> expression in the testcase.  The immediately tries to resolve
> the length while parsing the type-spec.
>
> While here, I've introduced an optimization that causes
> gfc_match_type_spec() to return early if the gfortran isn't
> going to be getting a type-spec.  This is done be peeking
> at the next character, if it is in [a-z], the we don't have
> a type spec.  OK to commit?
>
>
> 2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/82049
>         * match.c (gfc_match_type_spec): If the charlen is non-NULL, then
>         try to resolve it.  While here return early if possible.
>
> 2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/82049
>         * gfortran.dg/assumed_charlen_parameter.f90: New test.
>
>
> --
> Steve



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH] PR fortran/82049 -- resolve a charlen if possible

[Steve Kargl]

Thanks.  A version of the patch has been commit to 6-branch,
7-branch, and trunk.  One regression down, many more to go.

-- 
steve

On Wed, Feb 07, 2018 at 08:10:41AM +0000, Paul Richard Thomas wrote:
> Hi Steve,
> 
> That's OK for trunk and, if you are possessed of the intestinal
> fortitude, 6- and 7-branches.
> 
> Thanks
> 
> Paul
> 
> 
> On 7 February 2018 at 02:17, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
> > The attached patch fixes PR fortran/82049.  Prior to this
> > patch, gfortran was fouling up the resolution of the charlen
> > expression in the testcase.  The immediately tries to resolve
> > the length while parsing the type-spec.
> >
> > While here, I've introduced an optimization that causes
> > gfc_match_type_spec() to return early if the gfortran isn't
> > going to be getting a type-spec.  This is done be peeking
> > at the next character, if it is in [a-z], the we don't have
> > a type spec.  OK to commit?
> >
> >
> > 2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>
> >
> >         PR fortran/82049
> >         * match.c (gfc_match_type_spec): If the charlen is non-NULL, then
> >         try to resolve it.  While here return early if possible.
> >
> > 2018-02-06  Steven G. Kargl  <kargl@gcc.gnu.org>
> >
> >         PR fortran/82049
> >         * gfortran.dg/assumed_charlen_parameter.f90: New test.
> >
> >
> > --
> > Steve
> 
> 
> 
> -- 
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow