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
