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 Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
John-Silver



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

PostPosted: Fri Mar 09, 2018 10:34 pm    Post subject: Reply with quote

... to be strictly true shouldn't that message have ... "in ftn95" at the end ?

as I thought it runs ok in other compilers.

meej4 - I thought the root reason was that the compiler was being confused with the declaration of a variable with the same name as the function name - doesn't that validate the original error message ? (which is why I left it in.

to be honest the whole post has confused me to bits, especially trying to work out how the correct answer to the original code is 6. Shouldn't it be 4 ?
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Fri Mar 09, 2018 11:38 pm    Post subject: Reply with quote

John S,

I am ok with FTN95 not being changed to support that a function name/variable can be used for an ASSIGN variable. After all the use of ASSIGN is now obsolete and so not recommended.

I do understand mecej4's problem, in that it is legal Fortran that is contained in legacy code, although I am not sure how extensive. Making KA to KAS for the assign could easily overcome the problem (with the more informative error message) if this was an isolated use of this approach.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Sat Mar 10, 2018 12:31 am    Post subject: Re: Reply with quote

John-Silver wrote:
(i) I thought the root reason was that the compiler was being confused with the declaration of a variable with the same name as the function name ... (ii) to be honest the whole post has confused me to bits, especially trying to work out how the correct answer to the original code is 6. Shouldn't it be 4 ?

(i) No, as you can see in my reply to Eddie's second response in this thread. There, I showed code for a function that computes the factorial. The name of a function that returns a scalar value can be used as a local variable in the body of the function, in more contexts than result assignment.

(ii) The function is referenced with i = 3. The test "i.eq.2" fails, and the label 20 is assigned to ka. The assigned GOTO statement causes a jump to label 20, where the assignment "ka = i+i" is carried out. Since i = 3, ka is assigned the value 6.

I do not know how you concluded that ka should have been equal to 4.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sat Mar 10, 2018 2:56 pm    Post subject: Reply with quote

If the feature (ASSIGNed GOTO) was actually deleted in Fortran 95 et seq., then it is retained in a Fortran 95 compiler only as a favour to users, and isn't strictly legal, code-compliant, Fortran 95. (I say 'if' because that's what I read in various websites, but it may not be correct).

I think my position on retaining old features is clear, but then an ASSIGNed GOTO was always a rather crass thing in the first place, and surely has never been a commonplace feature of most people's source code.

Now there's something about the name FTN95 that may be of relevance here, but I can't put my finger on it just now. I wonder what it is?

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Sat Mar 10, 2018 5:06 pm    Post subject: Reply with quote

Eddie, I don't think that I can do better than to repost an exchange on this very question between two rather prominent people recently. One (A) is the author of a text book on Fortran published by Springer. The other (B) is a member of the Fortran Standards committee.

A wrote:
In the 25+ years since F90, it has been replaced by several newer standards, and therefore implementing something in an F90 compiler seems to be a waste of effort, especially since (a) the code is useless, and (b) the code is now illegal.


B wrote:
(a) doesn't matter to customers (b) is incorrect. It may not be valid F2003 or later, but in the real world, compilers that don't properly handle F77 and later are market failures. I'd go so far as to add F66 to that. As I wrote, a compiler that claims to support F90 needs to be able to correctly process any valid F90 source.


Some current Fortran compilers let you specify -std=f77, -std=f90, -std=f95, etc., thereby controlling which standard is used in deciding the warnings and error messages to issue.

Even if one wishes to redeem oneself by removing ASSIGN from a legacy code, exorcising the ASSIGNed GOTOs requires a compiler that can compile the old code correctly, if one wishes to have some assurance that the modified code gives the same results as the old code.

We have, in fact, two failed compilers that prove the point made by "B". Both were subsets of Fortran 90/95: Lahey's ELF90, and Imagine1's F.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sat Mar 10, 2018 9:54 pm    Post subject: Reply with quote

Springer seem to have published quite a few books on Fortran ...
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Mon Mar 12, 2018 1:53 pm    Post subject: Re: Reply with quote

John-Silver wrote:
... to be strictly true shouldn't that message have ... "in ftn95" at the end ? ... as I thought it runs ok in other compilers.

It is not easy for a compiler to emit a meaningful and pertinent error message. For the test program that I posted, the NAG compiler says:
Code:
Obsolescent: salasg.f, line 1: Fixed source form
Deleted feature used: salasg.f, line 14: ASSIGN statement
Error: salasg.f, line 14: ASSIGN to function name KA is not supported

which is very well said. On the other hand, the venerable F2C from AT&T Bell Labs says:
Code:
salasg.f:
   MAIN tasg:
   ka:
Error on line 12 of salasg.f: out_asgoto:  bad expr

This tells me where the problem is, but the rest of it may be understandable only to the compiler writers.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Mon Mar 12, 2018 9:42 pm    Post subject: Reply with quote

mecej4 wrote:
Quote:

It is not easy for a compiler to emit a meaningful and pertinent error message


... evidently.
When we complain about error messages not being 'meaningful' we don't target a specific compiler, it's a general failing (our own programs included !) imo.
Usually just out of laziness (the 'oh that error message was used here and is short so we'll use it here too' approach).

The only way to survive 'torture testing' in the long run is to diligently correct stuff !
If something is 'Fxx backward compatible' then it should, like any software, be just that.
Even if there's just 1 user who uses a particular feature in old code then it's worth the effort.

At the end of the day everyone knows the old phrase ....

Nothing Is Easy it just needs someone to give a little bit more time to fix it once and for all.

... but I guess ...

time is money ... money ... money - mind you, while often it's money for nothing it doesn't really take that much effort to go just that one step beyond to get the appreciation the effort deserves, even maybe the adulation of the crowd before no doubt having a nice cup of tea before skating away on the thin ice of a new dayagain, in circles once more no doubt, before cracking open the next [b]MESSAGE in a bottle[/b].

If music be the food of debug , sing on Wink
.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Mon Mar 12, 2018 10:29 pm; edited 3 times in total
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 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