[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