View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Jan 23, 2014 5:55 pm Post subject: 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.
Code: | 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.
Last edited by mecej4 on Sun Jan 26, 2014 12:22 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Jan 24, 2014 9:32 am Post subject: |
|
|
I have logged this for investigation. In the mean time you can use /inhibit_check 5 to bypass the problem. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Jan 24, 2014 9:00 pm Post subject: Re: |
|
|
PaulLaidler wrote: | 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. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sat Jan 25, 2014 10:07 am Post subject: |
|
|
nbf and p are not defined in the subroutine and they need to be integer, try this:
Code: | 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 |
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jan 25, 2014 3:04 pm Post subject: Re: |
|
|
IanLambley wrote: | 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. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sun Jan 26, 2014 11:03 am Post subject: |
|
|
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.
Last edited by IanLambley on Sun Jan 26, 2014 11:33 am; edited 2 times in total |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Sun Jan 26, 2014 11:21 am Post subject: |
|
|
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. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Jan 26, 2014 12:46 pm Post subject: Re: |
|
|
IanLambley wrote: | 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 http://forums.silverfrost.com/viewtopic.php?t=2722. 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: | 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: Code: | ftn95 /check hwmqt.f90
slink hwmqt.obj /debug
|
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Jan 26, 2014 12:56 pm Post subject: Re: |
|
|
davidb wrote: | 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. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sun Jan 26, 2014 3:27 pm Post subject: |
|
|
I compiled and ran it using Plato which seems to give the following options and runs OK.
Code: | 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: Code: | 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! |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Jan 26, 2014 8:08 pm Post subject: Re: |
|
|
IanLambley wrote: | I compiled and ran it using Plato which seems to give the following options and runs OK.
Code: | 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: Code: | 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? |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Mon Jan 27, 2014 12:53 am Post subject: |
|
|
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!! |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Jan 27, 2014 3:19 am Post subject: |
|
|
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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Jan 27, 2014 4:47 am Post subject: Re: |
|
|
JohnCampbell wrote: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Sat Mar 22, 2014 4:56 pm Post subject: |
|
|
This bug has now been fixed for the next release. |
|
Back to top |
|
|
|