[Bug fortran/96325] New: Invalid call of a type-bound procedure is accepted

[Bug fortran/96325] New: Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

            Bug ID: 96325
           Summary: Invalid call of a type-bound procedure is accepted
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 48928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48928&action=edit
Test case

Attached file contains an invalid call of a "type-bound procedure"

A = T%R1%GET(I)

where T%R1 is not a derived type at all, it is a REAL(REAL64).

With the following compiler:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

and compilation command:

$ gfortran -c -o test.o test.f90

the code is accepted. With version 10.1.0, the code is also accepted.
With version 8.3.0, the following error is reported:

test.f90:37:4:

     A = T%R1%GET(I)
    1
Error: Unclassifiable statement at (1)

[Bug fortran/96325] Invalid call of a type-bound procedure 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
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #0)
> Created attachment 48928 [details]
> Test case
> 
> Attached file contains an invalid call of a "type-bound procedure"
> 
> A = T%R1%GET(I)
> 
> where T%R1 is not a derived type at all, it is a REAL(REAL64).
> 
> With the following compiler:
> 
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.2.0 (GCC) 
> 
> and compilation command:
> 
> $ gfortran -c -o test.o test.f90
> 
> the code is accepted. With version 10.1.0, the code is also accepted.
> With version 8.3.0, the following error is reported:
> 
> test.f90:37:4:
> 
>      A = T%R1%GET(I)
>     1
> Error: Unclassifiable statement at (1)

Looks like a bug in your code.  Module m2 does not use anything from
module m1, so that appears to be a red herring.  There is no type
bound procedure.  Your code example then reduces to 

module m2

   type t2
      real r1
   end type

   contains

      pure subroutine s(t, a)
         implicit none
         type(t2), intent(in) :: t
         real, intent(out) :: a
         integer i
         a = t%r1%get(i)
      end subroutine

end module

and gfortran is telling you that it cannot parse 'a = t%r1%get(i)'
the part-ref for %get(i) is bogus, ie., the statement cannot be
classified as Fortran.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #2 from Kirill Chilikin <chilikin.k at gmail dot com> ---
Yes, there is no type-bound procedure really, and, yes, there is a bug in the
code (intentionally: it was called for the wrong variable, which is removed for
the test case). The module M2 indeed does not use anything from M1 (due to
simplification of the real code). And, yes, the gfortran should tell that this
statement is not classifiable - 8.3.0 does this, but 10.2.0 successfully
compiles the code without reporting any error.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #3 from Kirill Chilikin <chilikin.k at gmail dot com> ---
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)

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #4 from Kirill Chilikin <chilikin.k at gmail dot com> ---
Thus, this error (or, more exactly, absence of error) does not depend on the
presence of a type-bound procedure with the same name for another derived type.
The bug description should probably be modified.

[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

[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

[chilikin.k at gmail dot com]

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

--- Comment #7 from Kirill Chilikin <chilikin.k at gmail dot com> ---
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 
<fdumont@gcc.gnu.org>
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 <pault@gcc.gnu.org>
Date:   Mon Sep 2 19:54:02 2019 +0000

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

    2019-09-02  Paul Thomas  <pault@gcc.gnu.org>

            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  <pault@gcc.gnu.org>

            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

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 <pault@gcc.gnu.org>
> Date:   Mon Sep 2 19:54:02 2019 +0000
> 
>     re PR fortran/91589 (ICE in gfc_conv_component_ref, at
> fortran/trans-expr.c:2447)
>     
>     2019-09-02  Paul Thomas  <pault@gcc.gnu.org>
>     
>             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  <pault@gcc.gnu.org>
>     
>             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, &tmp);
          if (inquiry)
            sym = NULL;
+         else
+           {
+             component = gfc_find_component (sym, name, false, false, &tmp);
+             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

[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

--- 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, &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;

[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

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

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

[sgk at troutmask dot apl.washington.edu]

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

[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 <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.

[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 <sgk at troutmask dot apl.washington.edu> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r11-2487-ge41da82345fb01c4c2641c979a94a975d15312ab
Author: Paul Thomas <pault@gcc.gnu.org>
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  <pault@gcc.gnu.org>

    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

[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 <pault@gcc.gnu.org>:
> 

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> ---
(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

[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 <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 <gcc-bugzilla@gcc.gnu.org>
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>
> Rainer Orth <ro at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |ro at gcc dot gnu.org
>
> --- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> ---
> (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

[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 <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.thomas@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-bugzilla@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>>
>> Rainer Orth <ro at gcc dot gnu.org> changed:
>>
>>            What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>                  CC|                            |ro at gcc dot gnu.org
>>
>> --- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> ---
>> (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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at gcc dot gnu.org

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** 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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r11-2535-g863de9321813f947018cc60b06ba163ddcfbb5f2
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Tue Aug 4 07:53:50 2020 +0100

    Change testcase for pr96325 from run to compile.

    2020-08-04  Paul Thomas  <pault@gcc.gnu.org>

    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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r10-9231-g316aa7ad19cd5b2dacba61bd7cc930449108abe5
Author: Paul Thomas <pault@gcc.gnu.org>
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  <pault@gcc.gnu.org>

    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 #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r10-9232-gb2b53f0afceb09d20fe02ac1a014d49075f098e5
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Tue Aug 4 07:53:50 2020 +0100

    Change testcase for pr96325 from run to compile.

    2020-08-04  Paul Thomas  <pault@gcc.gnu.org>

    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]

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

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r9-9160-gb66dc7d363d26681113692f75ae9c033c12f3897
Author: Paul Thomas <pault@gcc.gnu.org>
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  <pault@gcc.gnu.org>

    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 #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r9-9161-g4d3d6343903f7ad79f0c70767bd106008fbfc346
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Tue Aug 4 07:53:50 2020 +0100

    Change testcase for pr96325 from run to compile.

    2020-08-04  Paul Thomas  <pault@gcc.gnu.org>

    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

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Paul Thomas <pault at gcc dot gnu.org> ---
Closed on 9- thru' 11-branches.

Thanks for the report and sorry for the belated fix.

Paul