[PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Steve Kargl]

Here are two possible patches for PR fortran/77391.  The first
patch treats the invalid code as a GNU Fortran extension as
gfortran current accepts the invalid code.  The second patch
enforces the standard.  As I think gfortran should encourage
standard conformance, I am inclined to commit the second patch.
I will however commit the most popular of the two patches tomorrow.
Voting starts now and will remain open for 24 hours (give or take
a few hours depend on when I awaken).

Patch 1:

Index: decl.c
===================================================================
--- decl.c	(revision 239762)
+++ decl.c	(working copy)
@@ -4798,11 +4798,23 @@ gfc_match_data_decl (void)
 
 ok:
   /* If we have an old-style character declaration, and no new-style
-     attribute specifications, then there a comma is optional between
+     attribute specifications, then a comma is optional between
      the type specification and the variable list.  */
   if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
     gfc_match_char (',');
 
+  /* F2008(C402): A colon shall not be used as a type-param-value except
+     in the declaration of an entity or component that has the POINTER
+     or ALLOCATABLE attribute.  */
+  if (current_ts.type == BT_CHARACTER && current_ts.deferred
+      && !(current_attr.allocatable || current_attr.pointer)
+      && !gfc_notify_std (GFC_STD_GNU, "Deferred length type parameter "
+			  "without POINTER or ALLOCATABLE attribute at %C"))
+    {
+      m = MATCH_ERROR;
+      goto cleanup;
+    }
+
   /* Give the types/attributes to symbols that follow. Give the element
      a number so that repeat character length expressions can be copied.  */
   elem = 1;

Patch 2:

Index: decl.c
===================================================================
--- decl.c	(revision 239762)
+++ decl.c	(working copy)
@@ -4798,11 +4798,24 @@ gfc_match_data_decl (void)
 
 ok:
   /* If we have an old-style character declaration, and no new-style
-     attribute specifications, then there a comma is optional between
+     attribute specifications, then a comma is optional between
      the type specification and the variable list.  */
   if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
     gfc_match_char (',');
 
+  /* F2008(C402): A colon shall not be used as a type-param-value except
+     in the declaration of an entity or component that has the POINTER
+     or ALLOCATABLE attribute.  */
+  if (current_ts.type == BT_CHARACTER && current_ts.deferred
+      && !(current_attr.allocatable || current_attr.pointer))
+    {
+      
+      gfc_error ("Deferred length type parameter without POINTER or "
+		 "ALLOCATABLE attribute at %C")
+      m = MATCH_ERROR;
+      goto cleanup;
+    }
+
   /* Give the types/attributes to symbols that follow. Give the element
      a number so that repeat character length expressions can be copied.  */
   elem = 1;

-- 
Steve

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Paul Richard Thomas]

Hi Steve,

I am strongly for the enforcement of the standard. Please apply patch #2.

Cheers

Paul


On 26 August 2016 at 20:27, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> Here are two possible patches for PR fortran/77391.  The first
> patch treats the invalid code as a GNU Fortran extension as
> gfortran current accepts the invalid code.  The second patch
> enforces the standard.  As I think gfortran should encourage
> standard conformance, I am inclined to commit the second patch.
> I will however commit the most popular of the two patches tomorrow.
> Voting starts now and will remain open for 24 hours (give or take
> a few hours depend on when I awaken).
>
> Patch 1:
>
> Index: decl.c
> ===================================================================
> --- decl.c      (revision 239762)
> +++ decl.c      (working copy)
> @@ -4798,11 +4798,23 @@ gfc_match_data_decl (void)
>
>  ok:
>    /* If we have an old-style character declaration, and no new-style
> -     attribute specifications, then there a comma is optional between
> +     attribute specifications, then a comma is optional between
>       the type specification and the variable list.  */
>    if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
>      gfc_match_char (',');
>
> +  /* F2008(C402): A colon shall not be used as a type-param-value except
> +     in the declaration of an entity or component that has the POINTER
> +     or ALLOCATABLE attribute.  */
> +  if (current_ts.type == BT_CHARACTER && current_ts.deferred
> +      && !(current_attr.allocatable || current_attr.pointer)
> +      && !gfc_notify_std (GFC_STD_GNU, "Deferred length type parameter "
> +                         "without POINTER or ALLOCATABLE attribute at %C"))
> +    {
> +      m = MATCH_ERROR;
> +      goto cleanup;
> +    }
> +
>    /* Give the types/attributes to symbols that follow. Give the element
>       a number so that repeat character length expressions can be copied.  */
>    elem = 1;
>
> Patch 2:
>
> Index: decl.c
> ===================================================================
> --- decl.c      (revision 239762)
> +++ decl.c      (working copy)
> @@ -4798,11 +4798,24 @@ gfc_match_data_decl (void)
>
>  ok:
>    /* If we have an old-style character declaration, and no new-style
> -     attribute specifications, then there a comma is optional between
> +     attribute specifications, then a comma is optional between
>       the type specification and the variable list.  */
>    if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
>      gfc_match_char (',');
>
> +  /* F2008(C402): A colon shall not be used as a type-param-value except
> +     in the declaration of an entity or component that has the POINTER
> +     or ALLOCATABLE attribute.  */
> +  if (current_ts.type == BT_CHARACTER && current_ts.deferred
> +      && !(current_attr.allocatable || current_attr.pointer))
> +    {
> +
> +      gfc_error ("Deferred length type parameter without POINTER or "
> +                "ALLOCATABLE attribute at %C")
> +      m = MATCH_ERROR;
> +      goto cleanup;
> +    }
> +
>    /* Give the types/attributes to symbols that follow. Give the element
>       a number so that repeat character length expressions can be copied.  */
>    elem = 1;
>
> --
> Steve



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Mikael Morin]

Hello,

Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> Here are two possible patches for PR fortran/77391.  The first
> patch treats the invalid code as a GNU Fortran extension as
> gfortran current accepts the invalid code.  The second patch
> enforces the standard.  As I think gfortran should encourage
> standard conformance, I am inclined to commit the second patch.
> I will however commit the most popular of the two patches tomorrow.
> Voting starts now and will remain open for 24 hours (give or take
> a few hours depend on when I awaken).
>

I don't think it's sufficient to check current_attr because of this case:

       character(:) :: a
       pointer :: a
       end

The statement should be accepted, and the check be postponed at a time 
after the symbol has been initialised, at resolution time for example.

Mikael

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Steve Kargl]

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
> 
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391.  The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.  The second patch
> > enforces the standard.  As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
> 
> I don't think it's sufficient to check current_attr because of this case:
> 
>        character(:) :: a
>        pointer :: a
>        end
> 
> The statement should be accepted, and the check be postponed at a time 
> after the symbol has been initialised, at resolution time for example.

Hmmm, yes indeed.  I guess I'll need to wade through resolve.c.

-- 
Steve

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Steve Kargl]

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
> 
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391.  The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.  The second patch
> > enforces the standard.  As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
> 
> I don't think it's sufficient to check current_attr because of this case:
> 
>        character(:) :: a
>        pointer :: a
>        end
> 
> The statement should be accepted, and the check be postponed at a time 
> after the symbol has been initialised, at resolution time for example.
> 

Well, this is interesting.  It seems that gfortran tried to detect
this issue.  In resolve.c(resolve_fl_variable) at lines 11443-11454,
one finds

  /* Constraints on deferred type parameter.  */
  if (sym->ts.deferred
      && !(sym->attr.pointer
	   || sym->attr.allocatable
	   || sym->attr.omp_udr_artificial_var))
    {
      gfc_error ("Entity %qs at %L has a deferred type parameter and "
		 "requires either the pointer or allocatable attribute",
		     sym->name, &sym->declared_at);
      specification_expr = saved_specification_expr;
      return false;
    }


resolve_fl_variable is never entered for

  program picky
  character(len=:),parameter :: ident2="which appears"
  end program picky

-- 
Steve

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Steve Kargl]

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
> 
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391.  The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.  The second patch
> > enforces the standard.  As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
> 
> I don't think it's sufficient to check current_attr because of this case:
> 
>        character(:) :: a
>        pointer :: a
>        end
> 
> The statement should be accepted, and the check be postponed at a time 
> after the symbol has been initialised, at resolution time for example.
> 

So, I've come up the following.  We now need to debate whether
Dominiq's observations mean that C402 does not apply to named
constant.

2016-08-26  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/77391
	* resolve.c (deferred_requirements): New function to check F2008:C402.
	(resolve_fl_variable,resolve_fl_parameter): Use it.
 
2016-08-26  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/77391
	* gfortran.dg/pr77391.f90: New test.


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 239762)
+++ gcc/fortran/resolve.c	(working copy)
@@ -11402,6 +11402,27 @@ resolve_fl_variable_derived (gfc_symbol 
 }
 
 
+/* F2008, C402 (R401):  A colon shall not be used as a type-param-value
+   except in the declaration of an entity or component that has the POINTER
+   or ALLOCATABLE attribute.  */
+
+static bool
+deferred_requirements (gfc_symbol *sym)
+{
+  if (sym->ts.deferred
+      && !(sym->attr.pointer
+	   || sym->attr.allocatable
+	   || sym->attr.omp_udr_artificial_var))
+    {
+      gfc_error ("Entity %qs at %L has a deferred type parameter and "
+		 "requires either the POINTER or ALLOCATABLE attribute",
+		 sym->name, &sym->declared_at);
+      return false;
+    }
+  return true;
+}
+
+
 /* Resolve symbols with flavor variable.  */
 
 static bool
@@ -11441,17 +11462,8 @@ resolve_fl_variable (gfc_symbol *sym, in
     }
 
   /* Constraints on deferred type parameter.  */
-  if (sym->ts.deferred
-      && !(sym->attr.pointer
-	   || sym->attr.allocatable
-	   || sym->attr.omp_udr_artificial_var))
-    {
-      gfc_error ("Entity %qs at %L has a deferred type parameter and "
-		 "requires either the pointer or allocatable attribute",
-		     sym->name, &sym->declared_at);
-      specification_expr = saved_specification_expr;
-      return false;
-    }
+  if (!deferred_requirements (sym))
+    return false;
 
   if (sym->ts.type == BT_CHARACTER)
     {
@@ -13570,6 +13582,10 @@ resolve_fl_parameter (gfc_symbol *sym)
       return false;
     }
 
+  /* Constraints on deferred type parameter.  */
+  if (!deferred_requirements (sym))
+    return false;
+
   /* Make sure a parameter that has been implicitly typed still
      matches the implicit type, since PARAMETER statements can precede
      IMPLICIT statements.  */
Index: gcc/testsuite/gfortran.dg/pr77391.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr77391.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77391.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+program picky
+character(len=:), parameter :: a="whoops" ! { dg-error "POINTER or ALLOCATABLE" }
+character(len=:) :: b="whoops" ! { dg-error "POINTER or ALLOCATABLE" }
+character(len=:) :: good
+pointer good
+end program picky


-- 
Steve

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

[Jerry DeLisle]

On 08/26/2016 05:06 PM, Steve Kargl wrote:
--- snip ---
>
> So, I've come up the following.  We now need to debate whether
> Dominiq's observations mean that C402 does not apply to named
> constant.
>

See my comment in the PR. The standard gives the explicit way to accomplish what 
the user wants to do by use of the asterisk.

C402 Holds

Jerry