|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Mar 07, 2018 3:58 pm Post subject: FTN95 fails to compile code with ASSIGNED GOTO |
|
|
ASSIGNED GOTO was deleted in Fortran 95, but FTN95 still supports this. Here is a test program that various versions of FTN95 (and even FTN77) fail to compile.
Code: | program tasg
implicit none
integer i,ka
i=3
print *,ka(i)
end
function ka(i)
implicit none
integer i, ka
!
ka = 0
if(i.eq.2)then
assign 10 to ka
else
assign 20 to ka
endif
goto ka
10 ka = i*i
return
20 ka = i+i
return
end |
The error message given by FTN95 8.10:
Code: | 0014) assign 10 to ka
*** Only INTEGER(KIND=3) variables may be ASSIGNed to |
This is surprising since ka is a default integer and, therefore, of kind = 3.
The correct output produced by running the program is "6".
It will be perfectly fine to give this bug low priority or to mark ASSIGNed GOTO and Format labels as "deleted" in FTN95. On the other hand, there are still codes in use (such as older versions of the BLAS ?NRM2 function) which contain the Assigned GOTO.
The bug is not encountered if the selector variable does not have the same name as the function.
Last edited by mecej4 on Thu Mar 08, 2018 1:53 am; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Mar 07, 2018 11:41 pm Post subject: |
|
|
Is the issue that ASSIGNed GOTO doesn't work, or that you can't (or shouldn't) have a variable with the same name as the function that it's in?
For example:
Code: | program tasg_a
implicit none
integer i,ka
i=3
print *,ka(i)
end
integer function ka(i)
implicit none
integer i, ka(10)
ka = 5*i
return
end |
which gives the answer 56687628, which certainly isn't 15. (v8.10, 32bit)
Personally, I'd never use a subprogram name as a variable (I thought you couldn't), but surely FTN95 ought to declare a warning that doing so is likely to produce odd results, and I'm more worried by my example succeeding without demur than I am by yours failing.
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 12:19 am Post subject: |
|
|
The deleted ASSIGN statement is peculiar. In a single program unit, you can have a scalar integer variable be one of (i) a scalar integer variable, (ii) a statement number that can only be used as the target of a GOTO, (iii) a Format statement number that can be used in an I/O statement. The programmer is supposed to know the nature of the current value of the variable. If the variable has an ordinary integer value (not a statement number), you should not use that variable in a GOTO or as the format no. in an I/O statement. If the variable is currently assigned a statement number, you should not use it in an arithmetic expression.
...
Your program contains a function that returns an array-valued result, and for such functions an explicit interface is required. The implicit interface is used by the compiler, and the program malfunctions. The function probably returns a pointer to an array, but your main program thinks that what is returned is a scalar integer.
Compiling with /check should have caught the missing interface.
Within the function code, you have two type declarations for ka, which is not allowed and the compiler should have flagged that as an error.
Here is a corrected version.
Code: | program tasg_a
implicit none
integer i
i=3
print *,ka(i)
contains
function ka(i)
implicit none
integer i, ka(10)
ka = 5*i
return
end function
end program |
Quote: | Personally, I'd never use a subprogram name as a variable. |
I am sure you do -- whenever you write code for a function subprogram and do not append a RESULT (<variable>) clause to the FUNCTION line. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Mar 08, 2018 12:09 pm Post subject: |
|
|
Mecej4,
You are being mischievous, as I suspect you know what I meant, and the function name isn't an ordinary variable useful for a variety of other things, such as jumping around the code, labelling FORMAT statements or anything else you care to mention.
Whatever was wrong with what I wrote, it neither generated a compiler or run-time error, which was ultimately the point - it just gave a daft answer. And all because the simplicity of proper Fortran was debauched.
"Fortran 90: nice language, too bad it's not Fortran"
(Dan Davison - not that I'm personally acquainted with the gentleman).
E |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 3:14 pm Post subject: |
|
|
It may be bad style to use a function name for other things in the corpus of that function, but as far as the language is concerned, with one or two exceptions, you are free to use the function name as you would use any local variable. For example:
Code: | program tfname
implicit none
integer i,n
do i=5,10
n = fact(i) ! fact: internal function name
print *,i,n
end do
stop
contains
integer function fact(i) ! function name
integer i,j
fact = i ! return variable initialised
j = i
do while (j > 1)
j = j-1
fact = fact*j ! fact used same way as local scalar integer
end do
return
end function
end program |
is bad in style and may give a compiler a hard time, but it is legal. Sometimes, we run into such code written by others, and such code has a place in a suite of testcases for "torture-testing" the compiler.
By the way, since this thread is about ASSIGNed GOTO, I may mention something that I just learned: almost no PC compiler provides debugging support for code containing ASSIGNED GOTOs. That fact should motivate one to get rid of ASSIGNED GOTO as soon as possible, because the deficiency is probably not worth rectifying at this time.
For the duration in which the variable is associated with a statement label, a debugger (not necessarily SDBG) may show (i) the address of the label (which is probably the explanation for your observing 56687628), (ii) an index into a list of labels that will be used in a subsequent GOTO <var>{<(list of labels)>)}, or (iii) nothing. Some compilers cause the variable to remember a previously assigned integer value, which I think is misleading. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Thu Mar 08, 2018 3:44 pm Post subject: |
|
|
I will make a note of this omission although I am not sure that the work required to add this feature is warranted. Was this construction (using an ASSIGN statement to deliver a function return value) ever included in a Fortran standard? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 4:37 pm Post subject: Re: |
|
|
PaulLaidler wrote: | I will make a note of this omission although I am not sure that the work required to add this feature is warranted. Was this construction (using an ASSIGN statement to deliver a function return value) ever included in a Fortran standard? |
Paul, it does not deliver a function return value.
Section 8.2.4 of the F90 standard describes ASSIGNed GOTO, and explains the multiple personalities of an integer variable that is assigned (i) a scalar integer value, (ii) a statement label of an executable statement in the function, and (iii) a Format statement label. When one of these three associations is current, the other two associations are suspended.
Section 12.5.2.2 describes how a function subprogram should work with or without a RESULT(resvar) suffix in the heading. In that section, it says "If RESULT is not specified, the result variable is function-name and all occurrences of the function name in execution-part statements in the scoping unit are references to the result variable. The value of the result variable at the completion of execution of the function is the value returned by the function."
Thus, we have to interpret the test program based on both sections: 8.2.4 and 12.5.2.2.
There is a current thread on Comp.Lang.Fortran on this topic: https://groups.google.com/forum/#!topic/comp.lang.fortran/zCqVH61EQO8 .
Thanks for your patience and interest.
Last edited by mecej4 on Sat Mar 10, 2018 1:28 am; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Mar 08, 2018 4:46 pm Post subject: |
|
|
Paul,
I think that Mecej4 has at least hinted at the answer - no, it isn't worth doing - but if you could detect the original error, you might consider providing a more informative error message. It seems to me that FTN95 does not always consider a FUNCTION name to be a simple INTEGER of default KIND=3, regardless of what the standard may or may not say.
FTN95 appears to deal with ASSIGNED GOTO perfectly well in a subroutine, so that probably needs no action.
Mecej4: would you agree?
I'm not sure that I would use such gymnastics to get a function return value, instead working it out with other variables and assigning it immediately before the RETURN that appears no longer to be required - primarily because I didn't know you could use it in the way you have!
Legality is not always the ultimate test of probity.
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 5:16 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: | Paul,
I think that Mecej4 has at least hinted at the answer - no, it isn't worth doing - but if you could detect the original error, you might consider providing a more informative error message. ... Eddie |
I agree with that. Here are some things that could be done: (i) does the current subprogram contain assigned GOTO statements? (ii) if so, is it a function? (iii) if so, is the function name the same as the assignee variable?
If the answers are "yes", "yes" and "yes", suppress any pending error messages and issue a message saying that the compiler cannot handle this construction (symbol overloading involving a deleted language feature), and suggest that the user change the variable name and try again. A single "no" implies that the compiler is capable of processing the code, and it proceeds as it does now.
Simply changing the wording of the error message from "Only INTEGER(KIND=3) variables may be ASSIGNed" to something more appropriate would also suffice. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Thu Mar 08, 2018 6:03 pm Post subject: |
|
|
I understand that my statement was not strictly correct but ka is associated both with an ASSIGN and with the function return.
I will take a look to see if the restriction can simply be removed without further work being entailed. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 6:56 pm Post subject: Re: |
|
|
PaulLaidler wrote: | ... but KA is associated both with an ASSIGN and with the function return. |
Yes, but not simultaneously! There are some similarities with the Pascal variant record type. And with EQUIVALENCE(J,R,D), where J is integer, R is real and D is double precision, and only one of the three can be defined at any time.
Quote: | I will take a look to see if the restriction can simply be removed without further work being entailed. | That would suffice. Thanks. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Mar 08, 2018 9:36 pm Post subject: |
|
|
mecej4 wrote, in the definition of the problem ...
Quote: | This is surprising since ka is a default integer and, therefore, of kind = 3. |
... maybe not for all compilers ? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Mar 08, 2018 9:43 pm Post subject: |
|
|
as for mecej4's suggestion for an augmented error message I'm al in favour but would suggest keeping the original message too, and also that an addition should be made as follows also ...
Variable <var name> is of KIND=<value here>
*** Only INTEGER(KIND=3) variables may be ASSIGNed to
Assigned GOTO contains a function with same name as the assigned variable
The compiler cannot handle this construction (symbol overloading involving a deleted language feature)
*Suggestion* Try changing the variable name and try again
Now THAT is a useful error message.
There could of course also be variants as necessary maybe even multiple suggestions _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Mar 08, 2018 9:58 pm Post subject: |
|
|
Quote: | ...suggest keeping the original message too ... |
Why would you want to keep the original message, which is wrong?
The types of the variables are all fine, and the program has no errors. The compiler was just not prepared for the function name to be used as a statement label variable, got confused, and gave an incorrect error message.
Please run the code with another compiler than FTN95 to see that there are no errors.
Code: | s:\LANG>lf95 asgerr.f
Lahey/Fujitsu Fortran 95 Express Release 7.10.02
Copyright (C) 1994-2004 Lahey Computer Systems. All rights reserved.
Copyright (C) 1998-2004 FUJITSU LIMITED. All rights reserved.
Compiling file asgerr.f.
Compiling program unit tasg at line 1:
Compiling program unit ka at line 7:
Encountered 0 errors, 0 warnings in file asgerr.f.
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
s:\LANG>asgerr
6
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Mar 09, 2018 9:12 am Post subject: |
|
|
It turns out that the addition of this feature would be non-trivial.
So the message has been clarified and will now give...
Code: | The use of the function result (KA) in an ASSIGN statement is not supported |
|
|
Back to top |
|
|
|
|
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
|