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

["paul.richard.thomas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #14 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Steve,

Your opinion of git and the change over to it is much the same as mine. I
have given it a go but had several "accidents" which put me off for a bit.
As for working on the branches.... well, I won't even begin to describe
what a dog's dinner that is. ChangeLogs are stuffed (or were) and I still
haven't found out how to update Bugzilla automatically. I haven't had the
energy to try again these last few months, largely because I am finding
home working so knackering. Sitting in front of the screen all day is
causing me irritated eyes and the occasional blinder of a headache.

I have taken note of your PRs with fixes on them - I'll maybe use them as
an adventure into gitland :-)

I see that Washington is just above the threshold of testing positivity and
that it is increasing. Has that resulted in a response yet? My younger son
lives in Mountain View and is going crazy with the new statewide
restrictions. They have two kids in a relatively small house and are both
trying to work from home. With no summer camps they are heading to another
bout of cabin fever.

galling
/ˈɡɔːlɪŋ/
Learn to pronounce
<https://www.google.com/search?rlz=1C1GCEU_enGB907GB908&sxsrf=ALeKk01WAFKiVjkfMVbAjEnkFQRgGWBs4Q:1596041502131&q=how+to+pronounce+galling&stick=H4sIAAAAAAAAAOMIfcRoyS3w8sc9YSmDSWtOXmPU4uINKMrPK81LzkwsyczPExLmYglJLcoV4pbi5GJPT8zJycxLt2JRYkrN41nEKpGRX65Qkq9QANSSD9STqgBVAQBz5NcbWQAAAA&pron_lang=en&pron_country=gb&sa=X&ved=2ahUKEwjc3Z_29fLqAhUIVBUIHdkNCtcQ3eEDMAB6BAgHEAg>
*adjective*

   1. causing annoyance or resentment; annoying.
   "it would be galling to lose your job because of a dispute with a
   customer"

Cheers

Paul

On Wed, 29 Jul 2020 at 17:19, sgk at troutmask dot apl.washington.edu <
gcc-bugzilla@gcc.gnu.org> wrote:

> 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
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.