When compiling modules it is sometimes useful to provide an interface for the contained procedure. For some of my procedures gfortran 7.1 is reporting an inconsistency in the ranks for some of the arguments. This has occurred for using a simple interface, a generic interface, or for using an interface for a procedure defined in a submodule. The following file causes the problem for fortran 7.1 module copy use, intrinsic :: iso_fortran_env, only : int8 interface module subroutine copy_byte_data( data, copy ) ! Chase's copier integer(int8), intent(in) :: data(:) integer(int8), allocatable, intent(out) :: copy(:) end subroutine copy_byte_data end interface contains subroutine copy_byte_data( data, copy ) ! Chase's copier integer(int8), intent(in) :: data(:) integer(int8), allocatable, intent(out) :: copy(:) if ( allocated( copy ) ) then deallocate( copy ) end if allocate( copy( size(data) ) ) copy = data return end subroutine copy_byte_data end module copy program test_copy use copy integer(int8) :: data(8) = 0_int8 integer(int8), allocatable :: acopy(:) write(*,*) 'DATA = ', data call copy_byte_data( data, acopy) write(*, *) 'ACOPY = ', acopy stop end program test_copy When compiled from the Terminal command line on Mac OS X 10.13.3, using the command gfortran test_copy.f90 I get the following response test_copy.f90:21:35: subroutine copy_byte_data( data, copy ) ! Chase's copier 1 Error: Shape mismatch in argument 'data' at (1) test_copy.f90:39:8: use copy 1 Fatal Error: Can't open module file ‘copy.mod’ for reading at (1): No such file or directory compilation terminated.
NAG, Intel and Sunf95 reject the code with a duplicate symbol error. After removing the 'module' before subroutine and some cleanup, NAG prints: NAG Fortran Compiler Release 6.1(Tozai) Build 6106 Error: pr84922.f90, line 14: Duplicate subprogram name COPY_BYTE_DATA detected at SUBROUTINE@COPY_BYTE_DATA So probably gfortran just produces a misleading error message...
FWIW I get the same misleading message for other variants of illegal code.
Confirmed from 6.4.0 up to trunk (8.0). The code compiles if the interface is removed from the module or the subroutine copy_byte_data is moved from the CONTAINS to its own TU. As hinted in comment 1, I think the code is invalid, but it should be rejected with a better error message.
My version of gfortran gives gfcx -c a.f90 a.f90:4:38: module subroutine copy_byte_data(data, copy) 1 a.f90:12:31: subroutine copy_byte_data(data, copy) 2 Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes with internal procedure defined at (2) a.f90:12:36: subroutine copy_byte_data(data, copy) 1 Error: Shape mismatch in argument 'data' at (1) Not sure if this is correct, though.
The code is definitely invalid, but the misleading error message did result in significant time lost by assuming the message was correct as to the problem. Note several other attempts to fix the problem resulted in the same message. > On Mar 21, 2018, at 7:28 AM, dominiq at lps dot ens.fr <gcc-bugzilla@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922 > > Dominique d'Humieres <dominiq at lps dot ens.fr> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Priority|P3 |P4 > Status|UNCONFIRMED |NEW > Last reconfirmed| |2018-03-21 > Target Milestone|--- |8.0 > Ever confirmed|0 |1 > > --- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > Confirmed from 6.4.0 up to trunk (8.0). The code compiles if the interface is > removed from the module or the subroutine copy_byte_data is moved from the > CONTAINS to its own TU. > > As hinted in comment 1, I think the code is invalid, but it should be rejected > with a better error message. > > -- > You are receiving this mail because: > You reported the bug.
My version of gfortran, 7.1, doesn’t give the first message, which is correct. The second message is incorrect. Either the clashing procedures should not be compared further, or the comparison of the shapes of the arguments should find that they match. > On Mar 21, 2018, at 12:59 PM, kargl at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922 > > kargl at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kargl at gcc dot gnu.org > > --- Comment #4 from kargl at gcc dot gnu.org --- > My version of gfortran gives > > gfcx -c a.f90 > a.f90:4:38: > > module subroutine copy_byte_data(data, copy) > 1 > a.f90:12:31: > > subroutine copy_byte_data(data, copy) > 2 > Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes with > internal procedure defined at (2) > a.f90:12:36: > > subroutine copy_byte_data(data, copy) > 1 > Error: Shape mismatch in argument 'data' at (1) > > Not sure if this is correct, though. > > -- > You are receiving this mail because: > You reported the bug.
> My version of gfortran gives > > gfcx -c a.f90 > a.f90:4:38: > > module subroutine copy_byte_data(data, copy) > 1 > a.f90:12:31: > > subroutine copy_byte_data(data, copy) > 2 > Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes > with internal procedure defined at (2) >a.f90:12:36: It seems your version has a non disclosed patch almost fixing this PR!-) > subroutine copy_byte_data(data, copy) > 1 > Error: Shape mismatch in argument 'data' at (1) It would be nice to skip this error. > Not sure if this is correct, though. Note that I have spent some time this afternoon marking any PR with "interface" in the summary as blocking the meta-bug pr29670.
On Wed, Mar 21, 2018 at 08:11:29PM +0000, w.clodius at icloud dot com wrote: > --- Comment #6 from William Clodius <w.clodius at icloud dot com> --- > My version of gfortran, 7.1, doesn’t give the first message, which is correct. > The second message is incorrect. Either the clashing procedures should not be > compared further, or the comparison of the shapes of the arguments should find > that they match. Of course, 7.1 does give the first message, as I just fixed the issue. But, I need to pull out a copy of the Standard to make sure the patch is correct. One still gets the second error message as gfortran runs a sequence of matchers in parse the code. She issues all errors that she finds, where some are run-on errors. Fix the first and others go away.
On Wed, Mar 21, 2018 at 08:15:57PM +0000, dominiq at lps dot ens.fr wrote: > > subroutine copy_byte_data(data, copy) > > 1 > > Error: Shape mismatch in argument 'data' at (1) > > It would be nice to skip this error. -fmax-errors=1 will do the trick. > > Not sure if this is correct, though. > > Note that I have spent some time this afternoon marking any PR with "interface" > in the summary as blocking the meta-bug pr29670. Some of those errors can't be fixed without a major rewrite of the gfortran frontend. The problem comes down to parsing into red-black trees is done almost exclusively without resolution. Attributes for symbols get coelesced into a single gfc_symbol. module dimension k(4) contains function k real k k = 1 end function end module These are 2 different 'k' entities. gfortran thinks it is a function return an array of 4 elements.
On Wed, Mar 21, 2018 at 01:23:32PM -0700, Steve Kargl wrote: > On Wed, Mar 21, 2018 at 08:11:29PM +0000, w.clodius at icloud dot com wrote: > > --- Comment #6 from William Clodius <w.clodius at icloud dot com> --- > > My version of gfortran, 7.1, doesn’t give the first message, which is correct. > > The second message is incorrect. Either the clashing procedures should not be > > compared further, or the comparison of the shapes of the arguments should find > > that they match. > > Of course, 7.1 does give the first message, as I just fixed not > the issue. But, I need to pull out a copy of the Standard > to make sure the patch is correct. Whoops.
Patch submitted.
FWIW I was told on comp.lang.fortran that the code is erroneous because of "The error message doesn't make much sense to me, but I think Note 12.2 in section 12.4.3.1 contains a clue to what's going on. It states: " "An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit.” Still the wording of the original error message suggests that there is an inconsistency in the matching process. > On Mar 21, 2018, at 2:24 PM, sgk at troutmask dot apl.washington.edu <gcc-bugzilla@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922 > > --- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- > On Wed, Mar 21, 2018 at 08:11:29PM +0000, w.clodius at icloud dot com wrote: >> --- Comment #6 from William Clodius <w.clodius at icloud dot com> --- >> My version of gfortran, 7.1, doesn’t give the first message, which is correct. >> The second message is incorrect. Either the clashing procedures should not be >> compared further, or the comparison of the shapes of the arguments should find >> that they match. > > Of course, 7.1 does give the first message, as I just fixed > the issue. But, I need to pull out a copy of the Standard > to make sure the patch is correct. > > One still gets the second error message as gfortran runs > a sequence of matchers in parse the code. She issues > all errors that she finds, where some are run-on errors. > Fix the first and others go away. > > -- > You are receiving this mail because: > You reported the bug.
On Thu, Mar 22, 2018 at 12:44:25AM +0000, w.clodius at icloud dot com wrote: > --- Comment #12 from William Clodius <w.clodius at icloud dot com> --- > FWIW I was told on comp.lang.fortran that the code is erroneous because of > > "The error message doesn't make much sense to me, but I think Note 12.2 > in section 12.4.3.1 contains a clue to what's going on. It states: " > > "An interface body cannot be used to describe the interface of an > internal procedure, a module procedure that is not a separate module > procedure, or an intrinsic procedure because the interfaces of such > procedures are already explicit.” gfortran was not checking /* C1246 (R1225) MODULE shall appear only in the function-stmt or subroutine-stmt of a module subprogram or of a nonabstract interface body that is declared in the scoping unit of a module or submodule. */ so you had invalid code reaching other parts of the compiler. It still reaches that part because gfortran tries it's best to make sense of possibly invalid code and continues to run a sequence of matchers. It queues up error messages. It then spews them to the terminal. Invalid code may lead to an appropriate error message and a number of run-on nonsense error messages. It may also lead to an erronous error message because it was queued by a previous matcher and not cleared.
Author: kargl Date: Thu Mar 22 21:42:07 2018 New Revision: 258784 URL: https://gcc.gnu.org/viewcvs?rev=258784&root=gcc&view=rev Log: 2018-03-22 Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/84922 * decl.c (get_proc_name): If the MODULE prefix appears in interface body, then it must appear on the contained subroutine or function. While here, fix nearby mis-indented code. 2018-03-22 Steven G. Kargl <kargl@gcc.gnu.org PR fortran/84922 * gfortran.dg/interface_42.f90: New test. * gfortran.dg/interface_43.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_42.f90 trunk/gcc/testsuite/gfortran.dg/interface_43.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
When compiling the following variant module copy use, intrinsic :: iso_fortran_env, only : int8 interface module subroutine copy_byte_data( data, copy ) ! Chase's copier integer(int8), intent(in) :: data(:) integer(int8), allocatable, intent(out) :: copy(:) end subroutine copy_byte_data end interface contains module subroutine copy_byte_data( data, copy ) ! Chase's copier integer(int8), intent(in) :: data(:) integer(int8), allocatable, intent(out) :: copy(:) if ( allocated( copy ) ) then deallocate( copy ) end if allocate( copy( size(data) ) ) copy = data return end subroutine copy_byte_data end module copy program test_copy use copy integer(int8) :: data(8) = 0_int8 integer(int8), allocatable :: acopy(:) write(*,*) 'DATA = ', data call copy_byte_data( data, acopy) write(*, *) 'ACOPY = ', acopy stop end program test_copy with revision 258784 I get pr84922_db_2.f90:20:42: module subroutine copy_byte_data( data, copy ) ! Chase's copier 1 Error: Shape mismatch in argument 'data' at (1) pr84922_db_2.f90:38:8: use copy 1 Fatal Error: Can't open module file 'copy.mod' for reading at (1): No such file or directory compilation terminated. Is the variant of module copy valid? If no, it is not detected; if yes, the Error: Shape mismatch in argument 'data' seems bogus.
On Fri, Mar 23, 2018 at 11:00:45AM +0000, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922 > > --- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > When compiling the following variant (code elided to keep this brief) > > Is the variant of module copy valid? If no, it is not detected; if yes, the > > Error: Shape mismatch in argument 'data' > > seems bogus. Don't know. I didn't investigate the "Shape mismatch" error. That's a different bug for a different PR.
GCC 8.1 has been released.
GCC 8.2 has been released.
GCC 8.3 has been released.
GCC 8.4.0 has been released, adjusting target milestone.