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

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #4 from Kirill Chilikin  ---
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] Invalid call of a type-bound procedure is accepted

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #3 from Kirill Chilikin  ---
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

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #2 from Kirill Chilikin  ---
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

2020-07-26 Thread 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.