[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

sgk at troutmask dot apl.washington.edu gcc-bugzilla@gcc.gnu.org
Wed Jul 29 16:18:57 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Jul 29, 2020 at 02:54:59PM +0000, pault at gcc dot gnu.org wrote:
> --- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> ---
> (In reply to kargl from comment #10)
> > (In reply to jvdelisle from comment #9)
> > > I regression tested the patch in comment 8 and see these failures.
> > > 
> > > FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
> > > FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors, line 14)
> > > FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess errors)
> > 
> > Thanks for testing.  Does the patch that follows fix the regressions?
> > gfortran treats components and type bound procedures separately.  I've
> > (hopefully) adapted the patch to whether foo is either.
> > 
> > Index: gcc/fortran/primary.c
> > ===================================================================
> > --- gcc/fortran/primary.c	(revision 280157)
> > +++ gcc/fortran/primary.c	(working copy)
> > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
> >  	  inquiry = is_inquiry_ref (name, &tmp);
> >  	  if (inquiry)
> >  	    sym = NULL;
> > +	  else
> > +	    {
> > +	      component = gfc_find_component (sym, name, false, false, &tmp);
> > +	      tbp = gfc_find_typebound_proc (sym, &t, name, false,
> > &gfc_current_locus);
> > +	      if (!component && !tbp)
> > +		{
> > +		  gfc_error ("%qs at %C is neither a component nor a type "
> > +			     "bound procedure of the derived "
> > +			     "type %qs", name, sym->name);
> > +		  return MATCH_ERROR;
> > +		}
> > +	    }
> >  
> >  	  if (sep == '%' && primary->ts.type != BT_UNKNOWN)
> >  	    intrinsic = true;
> 
> Hi Steve,
> 
> Given your comment 6, I set too first thing this morning and
> located the bug by searching the ChangeLogs for candidates. That
> I was the culprit is galling to say the least of it.

Don't be too galled (is that a word?).  You've contributed to so
many areas of the compiler and the Fortran language is only getting
more complicated!

For my patch, I noted that is_inquiry_ref tested for %re, %im,
%len, and %kind.  As that returns false, the only thing that
%foo(i) can be is either a component (which happens to be an
array) or type-bound procedure. 

> My version of the fix is:
> 
> index d73898473df..6f032fbabfd 100644
> --- a/gcc/fortran/primary.c
> +++ b/gcc/fortran/primary.c
> @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
> bool sub_flag,
>        else
>         component = NULL;
> 
> -      /* In some cases, returning MATCH_NO gives a better error message. Most
> -        cases return "Unclassifiable statement at..."  */
>        if (intrinsic && !inquiry)
> -       return MATCH_NO;
> +       {
> +         gfc_error ("%qs at %C is not an inquiry reference to an "
> +                    "intrinsic type", name);
> +         return MATCH_ERROR;
> +       }

This works for me.  Note, jerryd is in the process of committing
my patch as I do not use git (and currently no one is paying me
to learn git).

> > +		  gfc_error ("%qs at %C is not an inquiry reference to an "
> > +			     "intrinsic type", name);
> 
> or some such.

I suppose the above error message works.  The message I came up
with is due to the (i) in %foo(i).  Is this a typo for an array
or TBP?   Either way the error is now detected.

> 
> Also, you have to get rid of the comment and the dead code that
> was modified in my patch.
> 
> Thanks for the patch. OK for trunk when the error message is
> corrected and the comment plus dead code removed.

I do not know git.  I do not use git for my personal projects,
so there is no incentive for me to waste my time learning what
has become a bane.  I am stuck at svn r280157 (Jan 2020 or so).
AFAICT, from reading gcc mailing list arhives, the switch from
subversion to git was not publically discussed.  All discussion
(from a very small group of people) makes it clear the conversion
was going to happen.  It seems there was no consideration for
the negative impact the switch will have.  But, then again, 
gfortran is an after thought for most.

You'll find a bunch of patches attached to PRs, which need a
(hopefully new) gfortran committer to look:

mobile:kargl[204] ls pr*diff
pr30371.diff                    pr95586.diff
pr30371_umask.diff              pr95612.diff
pr30371_umask_sub.diff          pr95613.diff
pr30371_unlink_sub.diff         pr95614.diff
pr69101.diff                    pr95647.diff
pr85796.diff                    pr95708.diff
pr93635.diff                    pr95709.diff
pr95038.diff                    pr95710.diff
pr95340.diff                    pr95829.diff
pr95342.diff                    pr95980.diff
pr95352.diff                    pr95981.diff
pr95372.diff                    pr96013.diff
pr95446.diff                    pr96025.diff
pr95501.diff                    pr96038.diff
pr95502.diff                    pr96102.diff
pr95543.diff                    pr96320.diff
pr95584.diff                    pr96325.diff
pr95585.diff


More information about the Gcc-bugs mailing list