forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bug in FTN95 V7.00

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Jan 23, 2014 5:55 pm    Post subject: Bug in FTN95 V7.00 Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Jan 24, 2014 9:32 am    Post subject: Reply with quote

I have logged this for investigation. In the mean time you can use /inhibit_check 5 to bypass the problem.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Jan 24, 2014 9:00 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Sat Jan 25, 2014 10:07 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Jan 25, 2014 3:04 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Sun Jan 26, 2014 11:03 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Sun Jan 26, 2014 11:21 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Jan 26, 2014 12:46 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Jan 26, 2014 12:56 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Sun Jan 26, 2014 3:27 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Jan 26, 2014 8:08 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Mon Jan 27, 2014 12:53 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Jan 27, 2014 3:19 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Jan 27, 2014 4:47 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Mar 22, 2014 4:56 pm    Post subject: Reply with quote

This bug has now been fixed for the next release.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group