- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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)?
링크가 복사됨
5 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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" ... :)
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I would put the "100 lines of code" in a CONTAINed subroutine and CALL it.
