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 

FTN95 fails to compile code with ASSIGNED GOTO
Goto page 1, 2  Next
 
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: 1884

PostPosted: Wed Mar 07, 2018 3:58 pm    Post subject: FTN95 fails to compile code with ASSIGNED GOTO Reply with quote

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



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Mar 07, 2018 11:41 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 12:19 am    Post subject: Reply with quote

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



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Mar 08, 2018 12:09 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 3:14 pm    Post subject: Reply with quote

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


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

PostPosted: Thu Mar 08, 2018 3:44 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 4:37 pm    Post subject: Re: Reply with quote

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



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Mar 08, 2018 4:46 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 5:16 pm    Post subject: Re: Reply with quote

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


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

PostPosted: Thu Mar 08, 2018 6:03 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 6:56 pm    Post subject: Re: Reply with quote

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



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Mar 08, 2018 9:36 pm    Post subject: Reply with quote

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 ? Wink
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Mar 08, 2018 9:43 pm    Post subject: Reply with quote

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 ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Thu Mar 08, 2018 9:58 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Mar 09, 2018 9:12 am    Post subject: Reply with quote

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
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
Goto page 1, 2  Next
Page 1 of 2

 
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