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

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Paul Thomas  ---
Closed on 9- thru' 11-branches.

Thanks for the report and sorry for the belated fix.

Paul

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

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:4d3d6343903f7ad79f0c70767bd106008fbfc346

commit r9-9161-g4d3d6343903f7ad79f0c70767bd106008fbfc346
Author: Paul Thomas 
Date:   Tue Aug 4 07:53:50 2020 +0100

Change testcase for pr96325 from run to compile.

2020-08-04  Paul Thomas  

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: Change from run to compile.

(cherry picked from commit 863de9321813f947018cc60b06ba163ddcfbb5f2)

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

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:b66dc7d363d26681113692f75ae9c033c12f3897

commit r9-9160-gb66dc7d363d26681113692f75ae9c033c12f3897
Author: Paul Thomas 
Date:   Sun Aug 2 10:35:36 2020 +0100

This patch fixes PR96325. See the explanatory comment in the testcase.

2020-08-02  Paul Thomas  

gcc/fortran
PR fortran/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added to an intrinsic type component, emit the
error message in this function.

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: New test.
* gfortran.dg/pr91589.f90: Update error message.

(cherry picked from commit e41da82345fb01c4c2641c979a94a975d15312ab)

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

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:b2b53f0afceb09d20fe02ac1a014d49075f098e5

commit r10-9232-gb2b53f0afceb09d20fe02ac1a014d49075f098e5
Author: Paul Thomas 
Date:   Tue Aug 4 07:53:50 2020 +0100

Change testcase for pr96325 from run to compile.

2020-08-04  Paul Thomas  

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: Change from run to compile.

(cherry picked from commit 863de9321813f947018cc60b06ba163ddcfbb5f2)

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

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:316aa7ad19cd5b2dacba61bd7cc930449108abe5

commit r10-9231-g316aa7ad19cd5b2dacba61bd7cc930449108abe5
Author: Paul Thomas 
Date:   Sun Aug 2 10:35:36 2020 +0100

This patch fixes PR96325. See the explanatory comment in the testcase.

2020-08-02  Paul Thomas  

gcc/fortran
PR fortran/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added to an intrinsic type component, emit the
error message in this function.

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: New test.
* gfortran.dg/pr91589.f90: Update error message.

(cherry picked from commit e41da82345fb01c4c2641c979a94a975d15312ab)

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:863de9321813f947018cc60b06ba163ddcfbb5f2

commit r11-2535-g863de9321813f947018cc60b06ba163ddcfbb5f2
Author: Paul Thomas 
Date:   Tue Aug 4 07:53:50 2020 +0100

Change testcase for pr96325 from run to compile.

2020-08-04  Paul Thomas  

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: Change from run to compile.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #21 from Dominique d'Humieres  ---
*** Bug 96432 has been marked as a duplicate of this bug. ***

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

[paul.richard.thomas at gmail dot com]

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

--- Comment #20 from paul.richard.thomas at gmail dot com  ---
I got caught out by mime content blocking - trying again.

Paul

On Mon, 3 Aug 2020 at 09:26, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Thanks - this has been pointed out to me already by Dominique d'Humieres.
> I'll fix tonight or tomorrow.
>
> Paul
>
>
> On Sun, 2 Aug 2020 at 23:46, ro at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>>
>> Rainer Orth  changed:
>>
>>What|Removed |Added
>>
>> 
>>  CC||ro at gcc dot gnu.org
>>
>> --- Comment #18 from Rainer Orth  ---
>> (In reply to CVS Commits from comment #16)
>>
>> > gcc/testsuite/
>> > PR fortran/96325
>> > * gfortran.dg/pr96325.f90: New test.
>>
>> The new testcase produces
>>
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -O0  compilation failed to produce
>> executable
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -O1  compilation failed to produce
>> executable
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -O2  compilation failed to produce
>> executable
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -fomit-frame-pointer
>> -funroll-loops
>> -fpeel-loops -ftracer -finline-functions  compilation failed to produce
>> executable
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -g  compilation failed to
>> produce
>> executable
>> +UNRESOLVED: gfortran.dg/pr96325.f90   -Os  compilation failed to produce
>> executable
>>
>>   everywhere.  It cannot be
>>
>> ! { dg-do run }
>>
>>   when the compilation is expected to fail.
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>

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

[paul.richard.thomas at gmail dot com]

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

--- Comment #19 from paul.richard.thomas at gmail dot com  ---
Thanks - this has been pointed out to me already by Dominique d'Humieres.
I'll fix tonight or tomorrow.

Paul


On Sun, 2 Aug 2020 at 23:46, ro at gcc dot gnu.org 
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>
> Rainer Orth  changed:
>
>What|Removed |Added
>
> 
>  CC||ro at gcc dot gnu.org
>
> --- Comment #18 from Rainer Orth  ---
> (In reply to CVS Commits from comment #16)
>
> > gcc/testsuite/
> > PR fortran/96325
> > * gfortran.dg/pr96325.f90: New test.
>
> The new testcase produces
>
> +UNRESOLVED: gfortran.dg/pr96325.f90   -O0  compilation failed to produce
> executable
> +UNRESOLVED: gfortran.dg/pr96325.f90   -O1  compilation failed to produce
> executable
> +UNRESOLVED: gfortran.dg/pr96325.f90   -O2  compilation failed to produce
> executable
> +UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -fomit-frame-pointer
> -funroll-loops
> -fpeel-loops -ftracer -finline-functions  compilation failed to produce
> executable
> +UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -g  compilation failed to
> produce
> executable
> +UNRESOLVED: gfortran.dg/pr96325.f90   -Os  compilation failed to produce
> executable
>
>   everywhere.  It cannot be
>
> ! { dg-do run }
>
>   when the compilation is expected to fail.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #18 from Rainer Orth  ---
(In reply to CVS Commits from comment #16)

> gcc/testsuite/
> PR fortran/96325
> * gfortran.dg/pr96325.f90: New test.

The new testcase produces

+UNRESOLVED: gfortran.dg/pr96325.f90   -O0  compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90   -O1  compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90   -O2  compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90   -O3 -g  compilation failed to produce
executable
+UNRESOLVED: gfortran.dg/pr96325.f90   -Os  compilation failed to produce
executable

  everywhere.  It cannot be

! { dg-do run }

  when the compilation is expected to fail.

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

[jvdelisle at charter dot net]

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

--- Comment #17 from jvdelisle at charter dot net ---
(In reply to CVS Commits from comment #16)
> The master branch has been updated by Paul Thomas :
> 

Paul, I see you got the format just right. I stumbled on that part and then
decided to get out of town for sanity. I went up to the mountains and found the
official center of the universe (seriously, I know where it is now). In my half
of the State here we are in Insanity Phase 1.5 on Steve's scale.

Cheers all.  ;)

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:e41da82345fb01c4c2641c979a94a975d15312ab

commit r11-2487-ge41da82345fb01c4c2641c979a94a975d15312ab
Author: Paul Thomas 
Date:   Sun Aug 2 10:35:36 2020 +0100

This patch fixes PR96325. See the explanatory comment in the testcase.

2020-08-02  Paul Thomas  

gcc/fortran
PR fortran/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added to an intrinsic type component, emit the
error message in this function.

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: New test.
* gfortran.dg/pr91589.f90: Update error message.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  ---
Hi Paul,

Not sure how the UK is handling the pandemic.  Here, in
Washington we have 4 phases.  Phase 1 has the most
restrictions and phase 4 is the pandemic is over.  Most
of Washington made it into phase 2 (ie., small gathering,
restaurants, and stores opened with socialing distancing, etc).
Then the 4th of July holiday weekend happened, and now, many
places are back to phase 1 (ie., mandatory mask (which people
seem to ignore), gatherings of 5 (or 10) people, etc).  It
is interesting how people mistake common sense for infringement
of their civil liberties.  Of course, the political leadership
in the USA seems to be leading the pack with a lack common sense.

Transitioning to working from home has been interesting.
No small children to worry about.  But, my son was taking
graduate-level on-line courses on music composition for film
and multimedia, my wife was on-line, and I'm trying to
work.  Bandwidth was an issue.  Oh, I almost forgot.  I 
could often watch 2 EPL matches a day.

If you do look at one of my patches in a PR, feel free to 
ping me.  I had posted a list of PRs to comp.lang.fortran
trying to recruit new contributor.  Arjen has taken a 
baby step, but we could use more eyes.

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

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from 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

*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 
> ---
> On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> > --- Comment #12 from Paul Thomas  ---
> > (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, );
> > >   if (inquiry)
> > > sym = NULL;
> > > + else
> > > +   {
> > > + component = gfc_find_component (sym, name, false, false,
> );
> > > + tbp = gfc_find_typebound_proc (sym, , name, false,
> > > _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;

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> --- Comment #12 from Paul Thomas  ---
> (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, );
> >   if (inquiry)
> > sym = NULL;
> > + else
> > +   {
> > + component = gfc_find_component (sym, name, false, false, );
> > + tbp = gfc_find_typebound_proc (sym, , name, false,
> > _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.diffpr95586.diff
pr30371_umask.diff  pr95612.diff
pr30371_umask_sub.diff  pr95613.diff
pr30371_unlink_sub.diff pr95614.diff
pr69101.diffpr95647.diff
pr85796.diffpr95708.diff
pr93635.diffpr95709.diff
pr95038.diffpr95710.diff
pr95340.diffpr95829.diff
pr95342.diffpr95980.diff
pr95352.diffpr95981.diff
pr95372.diffpr96013.diff
pr95446.diffpr96025.diff
pr95501.diff 

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #12 from Paul Thomas  ---
(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, );
> if (inquiry)
>   sym = NULL;
> +   else
> + {
> +   component = gfc_find_component (sym, name, false, false, );
> +   tbp = gfc_find_typebound_proc (sym, , name, false,
> _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. 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;
+   }
   else if (component == NULL && !inquiry)
return MATCH_ERROR;


Just a couple of nits concerning your patch: The false typebound call appears
after the 'r1' components ref, which is not a derived type or class type. That
is why the test for an inquiry reference is appropriate and is tested for in
this block. Your error message comes up with t2 as being the type.

I suggest:
> +   gfc_error ("%qs at %C is not an inquiry reference to an "
> +  "intrinsic type", name);

or some such.

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.

Cheers

Paul

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

[jvdelisle at charter dot net]

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

--- Comment #11 from jvdelisle at charter dot net ---
(In reply to kargl from comment #10)
---snip---
> 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.
> 
---snip---

Patch at comment 10 passes patch provided in comment 10 passes regression
testing.

I will commit to trunk and use the original case as a test case tomorrow.

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

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(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, );
  if (inquiry)
sym = NULL;
+ else
+   {
+ component = gfc_find_component (sym, name, false, false, );
+ tbp = gfc_find_typebound_proc (sym, , name, false,
_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;

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

[jvdelisle at charter dot net]

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

jvdelisle at charter dot net changed:

   What|Removed |Added

 CC||jvdelisle at charter dot net

--- Comment #9 from jvdelisle at charter dot net ---
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)

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #7)
> Result of git bisect:
> 

(bisection removed)

> f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
> commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
> Author: Paul Thomas 
> Date:   Mon Sep 2 19:54:02 2019 +
> 
> re PR fortran/91589 (ICE in gfc_conv_component_ref, at
> fortran/trans-expr.c:2447)
> 
> 2019-09-02  Paul Thomas  
> 
> PR fortran/91589
> * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
> component ref, when the primary type is intrinsic.
> 
> 2019-09-02  Paul Thomas  
> 
> PR fortran/91589
> * gfortran.dg/pr91589.f90 : New test.
> 
> From-SVN: r275324

Thank for the bisection. The system I'm sitting in front of is too
slow to attempt a bisection.  I have developed a patch, which yields

% gfcx -c a.f90
a.f90:11:16:

   11 |a = t%r1%foo(1)   ! There is no foo component/TBP.
  |1
Error: 'foo' at (1) is not a component of the derived type 't2'

For the last testcase I posted.  I have not regression tested the
patch, so have no ideas if there are unforeseen side-effects.  I'll
just put the patch here for others to find.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 280157)
+++ gcc/fortran/primary.c   (working copy)
@@ -2240,6 +2240,16 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
  inquiry = is_inquiry_ref (name, );
  if (inquiry)
sym = NULL;
+ else
+   {
+ component = gfc_find_component (sym, name, false, false, );
+ if (!component)
+   {
+ gfc_error ("%qs at %C is not a component of the derived "
+"type %qs", name, sym->name);
+ return MATCH_ERROR;
+   }
+   }

  if (sep == '%' && primary->ts.type != BT_UNKNOWN)
intrinsic = true;

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

[chilikin.k at gmail dot com]

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

--- Comment #7 from Kirill Chilikin  ---
Result of git bisect:

$ git bisect log
git bisect start
# bad: [6e6e3f144a33ae504149dc992453b4f6dea12fdb] Update ChangeLog and version
files for release
git bisect bad 6e6e3f144a33ae504149dc992453b4f6dea12fdb
# good: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files
for GCC 8.
git bisect good 406c2abec3f998e9064919b22db62f38a7c0e7b9
# good: [7d75ea04cf6d9c8960d5c6119d6203568b7069e9] re PR c++/85437 (member
pointer static upcast rejected in a constexpr context)
git bisect good 7d75ea04cf6d9c8960d5c6119d6203568b7069e9
# good: [5fae049dc272144f8e61af94ee0ba42b270915e5] OpenACC Profiling Interface
(incomplete)
git bisect good 5fae049dc272144f8e61af94ee0ba42b270915e5
# bad: [271da732841345d3834cf458d47f8242ac5ef513] PR testsuite/92127: Disable
unrolling for some vect code model cases
git bisect bad 271da732841345d3834cf458d47f8242ac5ef513
# good: [4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9] [Ada] New parameter Quiet
for procedure GNAT.Command_Line.Getopt
git bisect good 4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9
# bad: [0968003dd08a9e9f83bee955bbdc259a781f044f] PR c++/91819 - ICE with
operator++ and enum.
git bisect bad 0968003dd08a9e9f83bee955bbdc259a781f044f
# good: [32b1d51f16fe56b34e979fcfba4bc74dbd3592a9] runtime: move osinit to Go
git bisect good 32b1d51f16fe56b34e979fcfba4bc74dbd3592a9
# bad: [a1fc3891ebb77c1bdf68ce70c074eb907d21771a] go/internal/gccgoimporter:
support embedded field in pointer loop
git bisect bad a1fc3891ebb77c1bdf68ce70c074eb907d21771a
# bad: [e7414688f16c4c9db2dacbc31da683887b4ba1bd] re PR middle-end/90501 (ICE:
address taken, but ADDRESSABLE bit not set)
git bisect bad e7414688f16c4c9db2dacbc31da683887b4ba1bd
# good: [a37ab089c22f8be834bb1b5fd4c0454224db9b0f] 2019-09-01  François Dumont 

git bisect good a37ab089c22f8be834bb1b5fd4c0454224db9b0f
# bad: [c6c2d1bc9bc3eb3606af6a198e74170bd906e199] re PR other/79543
(Inappropriate "ld --version" checking)
git bisect bad c6c2d1bc9bc3eb3606af6a198e74170bd906e199
# good: [1525fa83cc704ba18738eb2eab76a7f4d6bfde6b] re PR
tree-optimization/91632 (Probably wrong code since r275026)
git bisect good 1525fa83cc704ba18738eb2eab76a7f4d6bfde6b
# bad: [75f935365dba3eb5e9cbd11bc0d75009cad3d019] [AArch64] Add Linux hwcap
strings for some extensions
git bisect bad 75f935365dba3eb5e9cbd11bc0d75009cad3d019
# bad: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR fortran/91589 (ICE in
gfc_conv_component_ref, at fortran/trans-expr.c:2447)
git bisect bad f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
# good: [be0fb5484a64414878c31a1606b07175b54ecb90] re PR fortran/91552 (ICE
with valid array constructor)
git bisect good be0fb5484a64414878c31a1606b07175b54ecb90
# first bad commit: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR
fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447)

f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
Author: Paul Thomas 
Date:   Mon Sep 2 19:54:02 2019 +

re PR fortran/91589 (ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:2447)

2019-09-02  Paul Thomas  

PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref, when the primary type is intrinsic.

2019-09-02  Paul Thomas  

PR fortran/91589
* gfortran.dg/pr91589.f90 : New test.

From-SVN: r275324

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

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
This is a nasty bug, and I've run out of ideas on how to find a fix. :(

Simplified testcase

   implicit none

   type t2
  integer r1
   end type

   type(t2) :: t
   integer :: a

   a = t%r1%foo(1) ! There is no foo component/TBP
   if (a == 42) stop

   end

-fdump-tree-original gives

MAIN__ ()
{
  integer(kind=4) a;
  struct t2 t;

  a = 1;
  if (a == 42)
{
  _gfortran_stop_string (0B, 0, 0);
}
  L.1:;
}

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #3)
> I tested the reduced test case. It also compiles successfully with version
> 10.2.0, while it should not. With 8.3.0, an error is reported:
> 
> $ /usr/bin/gfortran -c -o test.o test2.f90
> test2.f90:14:9:
> 
>   a = t%r1%get(i)
>  1
> Error: Unclassifiable statement at (1)

Whoops.  I misread which version compiled the code and which one
issued the error.  This is, indeed a bug, a very strange bug!

For this code,

module m2

   implicit none

   type t2
  integer r1
   end type

   contains

  subroutine s(t, a)
 type(t2), intent(in) :: t
 integer, intent(out) :: a
 integer i
 i = t%r1
 a = t%r1%foo(i)
  end subroutine

end module

if I change t%r1%foo(i) to either t%r1(i) or t%r1%foo%bar(i), gfortran
will generate the unclassifiable statement error.  Compiling the code
with -fdump-tree-original reveals


s (struct t2 & restrict t, integer(kind=4) & restrict a)
{
  integer(kind=4) i;

  i = t->r1;
  *a = i;
}

i = t->r1 is correctly referencing the component of t.
*a = i is as-if t->r1->foo is an identity operator i