Bug 84922 - fortran reports inconsistency in rank of arguments in interface and contained procedures
Summary: fortran reports inconsistency in rank of arguments in interface and contained...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 7.1.0
: P4 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 29670
  Show dependency treegraph
 
Reported: 2018-03-17 02:55 UTC by William Clodius
Modified: 2021-05-17 08:08 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-03-21 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Clodius 2018-03-17 02:55:49 UTC
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.
Comment 1 Harald Anlauf 2018-03-17 17:34:48 UTC
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...
Comment 2 William Clodius 2018-03-17 21:27:16 UTC
FWIW I get the same misleading message for other variants of illegal code.
Comment 3 Dominique d'Humieres 2018-03-21 13:28:14 UTC
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.
Comment 4 kargls 2018-03-21 18:59:14 UTC
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.
Comment 5 William Clodius 2018-03-21 19:59:01 UTC
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.
Comment 6 William Clodius 2018-03-21 20:11:29 UTC
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.
Comment 7 Dominique d'Humieres 2018-03-21 20:15:57 UTC
> 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.
Comment 8 Steve Kargl 2018-03-21 20:24:34 UTC
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.
Comment 9 Steve Kargl 2018-03-21 21:18:55 UTC
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.
Comment 10 Steve Kargl 2018-03-21 21:19:29 UTC
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.
Comment 11 kargls 2018-03-21 22:19:51 UTC
Patch submitted.
Comment 12 William Clodius 2018-03-22 00:44:25 UTC
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.
Comment 13 Steve Kargl 2018-03-22 00:58:51 UTC
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.
Comment 14 kargls 2018-03-22 21:42:39 UTC
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
Comment 15 Dominique d'Humieres 2018-03-23 11:00:45 UTC
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.
Comment 16 Steve Kargl 2018-03-23 16:04:34 UTC
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.
Comment 17 Jakub Jelinek 2018-05-02 10:11:21 UTC
GCC 8.1 has been released.
Comment 18 Jakub Jelinek 2018-07-26 11:23:53 UTC
GCC 8.2 has been released.
Comment 19 Jakub Jelinek 2019-02-22 15:26:10 UTC
GCC 8.3 has been released.
Comment 20 Jakub Jelinek 2020-03-04 09:52:35 UTC
GCC 8.4.0 has been released, adjusting target milestone.