Bug in FTN95 V7.00

The 7.00 compiler, when used on the following test code with the /check option, gives an EXE that exhibits a runtime error ('Attempt to call a routine with argument number two containing too few array elements') at Line-23.

PROGRAM HWMQT

    implicit none
    integer                 :: nbf,p
    real,allocatable        :: gbz(:,:), gzwght(:)

    nbf = 5
    p   = 4

    allocate(gbz(nbf,p))
    allocate(gzwght(p))
    gzwght = 0.7
    call update(gbz,gzwght)
    write(*,*)gbz(1,1)

    stop

CONTAINS

subroutine update(ebz,zwght)

    implicit none

    real,intent(inout),target    :: ebz(nbf,p)
    real,intent(in)              :: zwght(p)

    real, pointer :: ptr

    ptr => ebz(1,1)
    ptr =  1.5+zwght(2)
    return

    end subroutine update

end program HWMQT

The line number in the error pop-up is for the CONTAINS line rather than the SUBROUTINE line below it; I do not see why the compiler thinks that there is a problem with the second argument -- it has been allocated with the same bounds as in the argument declaration.

Please note that the presence of the TARGET attribute for that argument is significant. If the code is modified to remove that attribute, the bug goes away.

I have logged this for investigation. In the mean time you can use /inhibit_check 5 to bypass the problem.

Quoted from PaulLaidler I have logged this for investigation. In the mean time you can use /inhibit_check 5 to bypass the problem.

Thanks for the fast response, Paul. Your suggested work-around takes care of the problem not only with the toy reproducer code above but also with the larger application with which I first encountered the issue.

nbf and p are not defined in the subroutine and they need to be integer, try this:

PROGRAM HWMQT 

    implicit none 
    integer                 :: nbf,maxs,maxm,maxl,p 
    real,allocatable        :: gbz(:,:), gzwght(:) 
    integer                 :: glev,maxo 

    nbf = 5 
    maxs= 2 
    maxm= 4 
    maxl= 3 
    p=4 
    maxo=max(maxs,maxm,maxl) 

    allocate(gbz(nbf,p)) 
    allocate(gzwght(p)) 
    gzwght = 0.7 
!**************************** modified line below
    call update(gbz,gzwght,nbf,p) 
    write(*,*)gbz(1,1) 

    stop 

CONTAINS 

!**************************** modified line below
subroutine update(ebz,zwght,nbf,p) 

    implicit none 
!**************************** new line below
    integer                 :: nbf,p 

    real,intent(inout),target    :: ebz(nbf,p) 
    real,intent(in)              :: zwght(p) 

    real, pointer :: ptr 

    ptr=>ebz(1,1) 
    ptr=1.5+zwght(2) 
    return 

    end subroutine update 

end program HWMQT

Quoted from IanLambley nbf and p are not defined in the subroutine and they need to be integer Please look again. The subroutine is CONTAINed in the program, and those two variables are declared and defined in the main program. The variables are available in the subroutine by host association.

Ummm, I suspected that but then couldn't understand why you needed to pass the arrays to the subroutine, because they were also 'CONTAINED' in the main program. But then I see that their names were changed within the program and hence they were passed.

Anyway, I ran three versions:

1. Your way - It worked
2. My way - It worked
3. No name change and removed array declarations in subroutine - It worked.

Which version of FTN95 are you using? I'm using 7.00. and I've tried with /check in checkmate win32 and .net, debug in win32 and .net and release in win32 & .net - can't get it to fail.

The program may not be strictly standard conforming.

In the declaration of ebz the first dimension nbf needs to be a constant.

(The second dimension may be a variable and is OK).

In any case, there is a bug here so it needs to be fixed.

Quoted from IanLambley Ummm, I suspected that but then couldn't understand why you needed to pass the arrays to the subroutine, ...

This is a pared down reproducer, derived from the real code discussed in https://forums.silverfrost.com/Forum/Topic/2406. As with most reproducers, much of the code may appear pointless. However, the purpose of a reproducer is to demonstrate that the compiler is not doing what it should, or is doing what it should not.

(https://forums.silverfrost.com/Forum/Topic/2406). As with most reproducers, much of the code may appear pointless. However, the purpose of a reproducer is to demonstrate that the compiler is not doing what it should, or is doing what it should not.

[quote:fd5108d618]Which version of FTN95 are you using? I'm using 7.00. and I've tried with /check in checkmate win32 and .net, debug in win32 and .net and release in win32 & .net - can't get it to fail. I used 7.00, as stated at the outset, and built for win32 at the command line: ftn95 /check hwmqt.f90 slink hwmqt.obj /debug

Quoted from davidb The program may not be strictly standard conforming. In the declaration of ebz the first dimension nbf needs to be a constant.

Thanks for your comments, but I don't see a problem in that respect.

Section 5.3.8.5 Assumed-size array of the F2008 standard has clause no. 6 saying 'If an assumed-size array has bounds that are not constant expressions, the bounds are determined on entry to the procedure.' None of the commonly used current Fortran compilers/program checkers complained about this point. One of them complained that I had gbz in a write statement but the variable was never defined. That is excusable because the definition is done in a sneaky way through a pointer in a different subprogram than the one containing the write statement.

I compiled and ran it using Plato which seems to give the following options and runs OK.

BINARY CHECK COLOUR DEBUG DELETE_OBJ_ON_ERROR ERROR_NUMBERS FPP LIST MINIMISE_REBUILD  NO_BANNER NO_QUIT NON_STANDARD SINGLE_THREADED UNLIMITED_ERRORS VS7

but when I use the command: ftn95 contained_error.f95 /check /list /debug /colour /minimise_rebuild /vs7 /link /fpp /unlimited

at the command line, it crashes. File extension .f90 or .f95 makes no difference. With or without /debug the same thing happens. Whether I use /link or the link command, the same thing happens. It works in Plato, but not when using the command line. I'm confused!

Quoted from IanLambley I compiled and ran it using Plato which seems to give the following options and runs OK.

BINARY CHECK COLOUR DEBUG DELETE_OBJ_ON_ERROR ERROR_NUMBERS FPP LIST MINIMISE_REBUILD  NO_BANNER NO_QUIT NON_STANDARD SINGLE_THREADED UNLIMITED_ERRORS VS7

but when I use the command: ftn95 contained_error.f95 /check /list /debug /colour /minimise_rebuild /vs7 /link /fpp /unlimited

at the command line, it crashes. ... I'm confused!

I found a quirk of the compiler that may explain some of the strange behaviour that you saw. The /BINARY option is supposed to be followed by a filename (naming the output .OBJ file). If, in the compilation invocation command line, the /BINARY option is given but the filename is not, and there are other options that follow, the compiler quits silently, neither producing an .OBJ file nor giving any messages. Thus, it is possible that you were simply reusing an old .OBJ file during the link step, and that .OBJ file was possibly compiled without /CHECK.

I ran the reproducer from Plato with the check option (but without the other options that you listed, many of which I felt were not needed or had no effect). The runtime error did show up.

Does this explation seem reasonable with your setup?

The BINARY option was added by Plato automatically and no doubt it adds the name of the object file before invoking the compiler. The default binary name is ok. I added the LIST option as the output specifies all the options used. The DELETE_ON_ERROR option should get rid of the object file if the compilation fails, preventing linking of an old file. I think Paul is the only one who can answer this. I'll try not to loose too much sleep!!

Mecej4,

You quote Section 5.3.8.5 Assumed-size array of the F2008 standard, however FTN95 only conforms to the Fortran 95 standard.

Your use of the variable nbf in the contained subroutine update for defining ebz might not be valid with F1995 ? I must admit I have only used CONTAINS in a module so am not familiar with the way you have used the variable nbf in this example.

I presume the problem would disappear if UPDATE was not in CONTAINS and nbf,p were arguments.

John

Quoted from JohnCampbell Mecej4, I presume the problem would disappear if UPDATE was not in CONTAINS and nbf,p were arguments. John

Making the subroutine UPDATE an internal procedure is a convenient way of providing the required explicit interface (such an interface is required because one or more arguments have the TARGET attribute). In an earlier version I had UPDATE as an external subroutine and I provided an interface block in the caller. The bug with /CHECK was actually noticed in this version first.

The FTN95 compiler processes the program correctly when /CHECK is not used. The test program has no language features that the compiler has any difficulty recognizing and compiling. It is only with the runtime checking code that a bug is seen.

This bug has now been fixed for the next release.