- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The previous version of intel visual fortran did not compile properly an"illegal"GOTO into an IF block from outside the block even with the optimizer turned off. Previous versions of the intel fortrancompiler did treat this properly.
Is there any hope for us losers who frequently branch at will intoIF blocks with this latest release (and the optimized turned off)?
Is there any hope for us losers who frequently branch at will intoIF blocks with this latest release (and the optimized turned off)?
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Turn the if blocks back into GOTOs, the way you would have done it 40 years ago, or run your code through a restructuring tool and fix any bad program flow which surfaces. Combining goto with if blocks this way has been clearly outside the standard, non-portable, and unreliable, from the first implementation of IF blocks. I guess "properly" means continuing to let something slip by unchecked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The current version is 12.0. The most recentprevious version was 11.1.067, which accepted invalid code such as the following with a warning. What is an"improper"way of handling code such as this?
Can you make a decent case for allowingsuch "illegal" jumps? If not, I may regard your request as equivalent to your asking mefor helpinshooting yourself in the foot "properly" ... :)
[fxfortran] program shootfoot real x,y y=0.0 if(y.ne.0.0)then 10 x=1.0/y endif if(x.lt.100.0)then y=y*0.5 goto 10 endif write(*,*)x,y end [/fxfortran]
Can you make a decent case for allowingsuch "illegal" jumps? If not, I may regard your request as equivalent to your asking mefor helpinshooting yourself in the foot "properly" ... :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In my opinion, humble as it is, one who is a proponent of GOTOs should not be a proponent of that code!
Pre-If-then-else, we would have shied away from allowing that!
Unreadable, to say the least.
Linda
Pre-If-then-else, we would have shied away from allowing that!
Unreadable, to say the least.
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, here's a good example
IF ( X .EQ. 5 ) THEN
8 100 LINES OF CODE
ELSE IF( X.EQ.6 ) THEN
10 LINES OF CODE
GOTO8
ENDIF
basically one wants to re-use the 100 lines of code, avoiding having to re-write multiple times.
Granted one could write
IF ( X .EQ. 5 .OR X.EQ.6) THEN
IF ( X.EQ. 6) THEN
10 LINES OF CODE
ENDIF
8 100 LINES OF CODE
ENDIF
which can get even messier if there aremany conditions all which need to branch to label 8
IF ( X .EQ. 5 ) THEN
8 100 LINES OF CODE
ELSE IF( X.EQ.6 ) THEN
10 LINES OF CODE
GOTO8
ENDIF
basically one wants to re-use the 100 lines of code, avoiding having to re-write multiple times.
Granted one could write
IF ( X .EQ. 5 .OR X.EQ.6) THEN
IF ( X.EQ. 6) THEN
10 LINES OF CODE
ENDIF
8 100 LINES OF CODE
ENDIF
which can get even messier if there aremany conditions all which need to branch to label 8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would put the "100 lines of code" in a CONTAINed subroutine and CALL it.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page