does assigned go to work as it should ?

[e745200]

Hi,

having said that I am removing all obsolete features from the code I am working on, I think there is something incorrect in how Intel Fortran deals with assigned goto statements: it seems to ignore any list of labels.

According to the documentation, "If a list of labels appears, the statement label assigned to the variable must be one of the labels in the list."

Nevertheless, nothing special happens if this is not the case, and the programs flows as if the list of labels was not specified.

A short example will show it.

$ cat tassgoto.f90

      integer :: j

      assign 10 to j
      go to j , ( 1, 2 ) 
      print *, "d'oh"
      stop   

 1    print *, 1
      stop   
 2    print *, 2
      stop   
 10   print *, 10
      stop   
      end    

$ ifort -V tassgoto.f90
Intel(R) Fortran Intel(R) 64 Compiler for applications running 
on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

 Intel(R) Fortran 16.0-1540
GNU ld version 2.20.51.0.2-5.42.el6 20100205

$ ./a.out
          10

Is there something I'm missing ?

[TimP]

That's a new one for me. In the past, I've seen compilers which passed to the next sequential statement on an out of range index, and others which threw a run-time failure in the same case.

I've put many hours of work into eliminating assigned goto, as there was usually a more straightforward way, not always easy to find in spaghetti code.

[e745200]

The issue is exactly that one: I am removing the assigned GOTOs and - of course - I want to replicate the same behavior with standard-compliant constructs.

But the previous beaviour (in case of assigned label not present in the list) seems not clearly documented.

The standard reads :
GO TO i [ (s [,s]...)]
...
"If the parenthesized list is present, the statement label assigned to i must be one of the statement labels in the list."

Which is exactly what the intel fortran  documentation says. Incidentally, I had the chance to check that also XLfortran documentation reads the same, and the program compiled with XLF behaves in the same way.

In no place I have seen what should happen if the assigned label is not in the list. I would expect a run-time error, otherwise the expression "must be one of the statement labels in the list" loses its meaning ...

[Steven_L_Intel1]

This is a requirement on the programmer. If the rule is not obeyed, the results are unspecified by the standard. I was unaware, until this post, that you could have a label list on assigned GOTO, but indeed that's how it shows in F77. 

My advice would be to complete removal of assigned GOTO and move on.

[e745200]

Thanks to all.

Steve, for sure I'm going to remove all assigned GOTOs,  having them a list of legal labels or not, as I am restructuring the code and removing ALL of the GOTOs.

The issue is to know the original behavior when the assigned label is not one of the list:
 - run-time error ?
 - continue the execution with the statement following that assigned goto (as it happens in the computed goto) ?
 - ignore the list and go to the assigned label anyway ?

The last one is the behavior I've experienced both with the intel and xlf compilers.

None of the compatibility compiler options seems to affect this behavior.

Then I'm prone to assume that, not being specified a behavior in the standard, the list of legal labels is simply ignored by those compilers. On the other hand, gfortran deals with it as a syntax error.

[TimP]

If you don't know which compiler it was originally written for, you have no hope of determining "original behavior."  One might think that someone expected it to work as it does with some compilers you have been using, otherwise they might have had to correct it.

Prior to Fortran 90, there wasn't even a requirement for a compiler to include an option to diagnose use of extensions beyond the standards.  Steve appears to expect assigned goto to work without a label list, so I'm prepared not to be surprised if the label list is ignored by compilers descended from DEC Fortran.

[mecej4]

I had not known about the optional label list of assigned GOTO statements until I saw this thread. This is quite a strange case where the Fortran standard says "...the value currently assigned to the variable should be one of the labels in the list if the list is specified", but says nothing about what should happen if that requirement is violated, so the catch-all rule of "undefined behavior" may be expected to apply. On the other hand, if the requirement is satisfied, the assigned GOTO behaves in the same way whether or not the label list is provided, so the effect of having a label list is either "nothing" or "undefined", and the label list has little reason to exist unless a vendor-provided extension defines what happens when the assigned value is not in the list.

What is a reasonable response from any compiler that still supports assigned go to statements and supports the optional label list when the assigned value is not one of the values in the list? I suggest that control should go to the next executable statement.

[Steven_L_Intel1]

Since the standard doesn't provide an interpretation for this usage, anything could happen. I'd be a bit uncomfortable about ignoring the ASSIGN, though I suppose one could treat this similar to SELECT CASE, where if there is no match and no CASE DEFAULT, it just flows past the SELECT block.

I can tell you that we're not going to change the behavior of this usage.

[mecej4]

Steve Lionel (Intel) wrote:

Since the standard doesn't provide an interpretation for this usage, anything could happen. I'd be a bit uncomfortable about ignoring the ASSIGN, though I suppose one could treat this similar to SELECT CASE, where if there is no match and no CASE DEFAULT, it just flows past the SELECT block.

The only meaningful purpose of the label list, as far as I can see it, is to modify the behavior of the assigned GOTO when the variable has a value that is not in the list. In the present implementation, that purpose is not met.

I can tell you that we're not going to change the behavior of this usage.

What should the OP do? He is trying diligently to get rid of assigned go to statements in old code, and he wants the code to function in the same way as it has in the past. He is handicapped by not knowing (except by trial and error) what the current behavior is, since the documentation does not stipulate it. As of now, I think that he should simply ignore the label lists in his code while doing the code updating. Do you agree with that?

There is one more statement in the standard about assigned go to-s that I do not understand:

     "A label may appear more than once in the label list of an assigned GO TO statement".

What purpose is (was) served by repeating a label in the list?

[TimP]

We've already pointed out that the behavior of this code differs between compilers, and what the most usual possibilities were, some of them probably excluded if one assumes that the code ran at all on the unspecified original platform.

[e745200]

I'll give you another piece of information: I was able to verify that the optional list of lables is ignored in VSFORTRAN and in Portland Fortran too (i.e. they both bahave as depicted in the example above).

Additionally, at compile time, VSFORTRAN clearly signals an unlabelled statement strictly following the ASSIGNED GOTO as unreachable code. This totally discards the option that in case of an assigned value not present in the list the program would execute that statement (for that compiler).

At this point, although my experience is limited to a buch of different compilers, I would assume that - possibly due to the incompleteness of the specification - the list-of-labels feature has never been  implemented as a mandatory restriction on the value of the assigned label, and it is always ignored, with the exception of gfortran by which it is dealt with as a syntax error.

What I do not understand is why all the manuals of all the mentioned compilers do not say anything clear about this issue, and remain as indetermined as the standard is.

Thanks to all of you.

[Steven_L_Intel1]

The manuals are essentially paraphrasing the standard - you'll find this a lot across the industry. 

[e745200]

Steve Lionel (Intel) wrote:

The manuals are essentially paraphrasing the standard - you'll find this a lot across the industry. 

Yes, of course: it is cheaper and does not create (too much more) confusion when passing from a compiler to another, at least while reading documentation.

I have read all relevant paragraphs of the mentioned compilers manuals and can confirm what you said.

But the compilers creators implement the standard in a specific way, they make a choice when the standard is indetermined,  and the users would be grateful to them if they would express the solution they adopted in the cases left indetermined by the standard, as well as they do for their more explicit extensions to the standard.

I found it singular that no one did it in this case. It would have been an added value.

[mecej4]

After reading the information given in #11, I looked up the IBM VS Fortran manual (http://publibfp.boulder.ibm.com/epubs/pdf/afbr1001.pdf ). The last paragraph of p. 136 says:

Any executable statement immediately following the assigned GO TO statement should have a statement label; otherwise, it can never be referred to or executed.

[jimdempseyatthecove]

Mecej4,

While the compiler can catch an incorrect ASSIGN, and some instances where ASSIGN not executed as last assignment, it might not catch never been ASSIGN'ed or VAR = numberNotLabel. I think it is undefined behavior as to what happens in the latter two erroneous situations. Early compilers may have caused crash due to address being stored in the variable. If the compiler could generate code to catch those scenarios, then the vendor could have chosen to have the undefined behavior to fall through (or crash, or assert error).

Jim Dempsey

[mecej4]

Jim, you are bringing up another aspect of Assigned GoTo that, despite being open to criticism as a magnet for errors, has not been debated in this thread. The documentation makes it clear that, in effect, there can be variables with one name  and of two different types (integers and labels; three types, if you include Format labels) at different times.

The initial post in this thread asked, in essence, "what is the expected behavior when the assigned label is not one of those in a label-list that has been specified?" The answer appears to be "undefined", whether from the perspective of the Fortran IV, etc., standard or many well-known Fortran compilers.

[e745200]

mecej4 wrote:

The answer appears to be "undefined", whether from the perspective of the Fortran IV, etc., standard or many well-known Fortran compilers.

For sure the behavior is  "undocumented" but it does not seem to be "unpredictable", as "undefined" would imply. Yes, this distinction is disputable, but all the compilers I checked have shown the same behavior: if they accept the list at compile-time (only gfortran does not), they simply ignore it at run-time.

May we assume that the standard does not express a specific behavior simply because it is not different from the "basic" behavior, the one it has when the list is missing ? The tests I made seem to be in line with this assumption. Has anyone a different experience ?

A rephrase of the initial question could be: "Has any compiler ever implemented a run-time check, when executing an assigned go to, on the label-value assigned to the driving variable ?"

[TimP]

e745200 wrote:

A rephrase of the initial question could be: "Has any compiler ever implemented a run-time check, when executing an assigned go to, on the label-value assigned to the driving variable ?"

It was pointed out more than once that some past compilers threw a run-time failure on code such as presented here.  It may be slightly academic, as there is no chance of my wanting to use those old compilers again.

Again, there was no standard requirement for a compiler to offer a means to check for standards compliance until Fortran 90.   This seems not to be a case where one could demand an indication under standards checking, if the target lable list was always optional, and assigned goto was deprecated.

[e745200]

Tim P. wrote:

It was pointed out more than once that some past compilers threw a run-time failure on code such as presented here.  It may be slightly academic, as there is no chance of my wanting to use those old compilers again.

Again, there was no standard requirement for a compiler to offer a means to check for standards compliance until Fortran 90.   This seems not to be a case where one could demand an indication under standards checking, if the target lable list was always optional, and assigned goto was deprecated.

Sorry if I gave the annoying impression of having missed it. However I was just rephrasing the question, not proposing it again.
As far as I am concerned, the case is solved, and I will restructure the old code just ignoring the list of labels. This seems in line with the kind of support to this deleted statement the compilers have been giving in the last two decades. 

Thanks to all of you for your attention.

[mecej4]

e745200, I understand your concerns, and here is something that you may find useful. The OpenWatcom F77 Language Ref. Man. (http://froebe.net/blog/wp-content/uploads/2014/04/Open-Watcom-1.8-FORTRAN-77-Language-Reference-Open-Watcom.pdf ) says on p. 81:

If a list of statement labels is present then the statement label assigned to i must be in the list. If it is not in the list, an error will occur when the assigned GO TO statement is executed. Unlike the computed GO TO statement, execution does not continue with the next statement.

Your program of #1, cast into fixed format source, runs with OpenWatcom F77 1.9 and prints "d'oh", however, so the implementation may not quite follow that quotation. Nevertheless, it may be useful to run your unmodified program with Watcom F77 to establish a baseline set of results. If they differed from those that IFort gives you, you would have some digging to do!

The IBM VS Fortran II manual at http://www.eah-jena.de/~kleine/history/languages/C28-6054-4_7090_FORTRANII.pdf describes on p. 15 a restriction on assigned GOTO within the range of a DO loop.

[e745200]

mecej4 wrote:

Your program of #1, cast into fixed format source, runs with OpenWatcom F77 1.9 and prints "d'oh", however, so the implementation may not quite follow that quotation.

That means that the message I chose was appropriate !  ;-)

Kidding apart, thanks a lot for your info.

The OpenWatcom F77 claimed behavior is the one I would expect in case of a label missing in the list, given the "must be" prescribed by the standard !

Well, I think the best thing to do, when removing the assigned GOTOs, which is anyway a must, is to check carefully that the list always contains all the possible values assigned to the driving variable; in this happy case we can say that it was written only for an excess of zeal of the programmer or because, as the Fortran II manual reads, it was not optional at that time, for that compiler.

When the assigned value is not in the list, and there is no possibility of reproducing an unknowkn "original" behavior, as Tim P. said, we should adopt a sound alternative.

Thanks again.