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-bugzi...@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.
