- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
IFORT does not have this issue.
In following statement dynamicarr is allocated when noption=1. This statement executed fine in IFORT but IFX gives access violation exception.
noption = 0
if (noption.eq.1 .and. dynamicarr(1).eq.0) then
Same exception occurs on optional parameter check. If optional parameter is not passed to a routine then following statement gives access violation exception.
if (PRESENT(ioptional) .AND. ioptional.gt.0) then
- タグ:
- ifx
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Fortran as per the standard does not enforce short-circuiting such composite logical expressions. That it seems to have worked in IFORT is a mere coincidence. You should simply not rely on it, as it is quite possibly depending on the compiler options you use besides the complexity of the expression and many other things. Other languages do enforce this (C for instance) or have special operators (Ada, IIRC). There have been proposals for Fortran - operators like .andthen. and .orelse. But they are not part of any standard at this moment.
コピーされたリンク
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Fortran as per the standard does not enforce short-circuiting such composite logical expressions. That it seems to have worked in IFORT is a mere coincidence. You should simply not rely on it, as it is quite possibly depending on the compiler options you use besides the complexity of the expression and many other things. Other languages do enforce this (C for instance) or have special operators (Ada, IIRC). There have been proposals for Fortran - operators like .andthen. and .orelse. But they are not part of any standard at this moment.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Replace
if (noption.eq.1 .and. dynamicarr(1).eq.0) then
by
if (noption.eq.1) then
if( dynamicarr(1).eq.0) then
...
end if
The compiler is allowed to evaluate expressions in any order, so sub-expressions should be possible to evaluate in any order.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Workarounds based on Fortran 2018 and earlier standards are shown upthread.
Starting Fortran 2023, the following will be an option given the conditional nature of the desired instructions:
if ( noption == 1 ? ( dynamicarr(1) == 0 ? .true : .false. ) : .false. ) then
..
if ( present(ioptional) ? ( ioptional > 0 ? .true. : .false. ) : .false. ) then
..
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Fortran 2023 adds conditional expressions that will help you here, once supported. For example,
if (noption .eq. 1?dynamicarr(1) .eq. 0) ...
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
@Steve_Lionel wrote:
Fortran 2023 adds conditional expressions that will help you here, once supported. For example:
if (noption .eq. 1?dynamicarr(1) .eq. 0) ...
However, the standard requires a clause for when `scalar-logical-expr' (e.g., the expression "noption .eq. 1") evaluates to `false`:
Thus a colon and a following expr is required, say the following lines, making the statement a bit more verbose than a Fortranner might be prone to presume:
if ( noption == 1 ? ( dynamicarr(1) == 0 ? .true : .false. ) : .false. ) then
..
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
if ( noption == 1 ? ( dynamicarr(1) == 0 ? .true : .false. ) : .false. ) then
This will be a beast to debug, @mecej4 is the best solution for maintainability and not obscureness.
It is like LISP without the elegance.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I expect most uses will be as expressions in assignments rather than if-then. Conditional arguments are a related feature that have some interesting use cases.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Thank you to all for providing the alternatives.
The issue is that, it was working in IFORT but failed in IFX.
I am working on large code base and the alternatives will be my last option.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
@NasarAliwrote:Thank you to all for providing the alternatives.
The issue is that, it was working in IFORT but failed in IFX.
I am working on large code base and the alternatives will be my last option.
I think that you are making a grave mistake here. If the code base that you are working on may be used to generate results that will be utilized to manufacture a product, deliver a service or to support decisions that may affect someone's life or a company's viability, and something unfortunate happens as a result of not fixing this bug, you are at risk of being blamed. The risk is higher because you have been informed of the risk and choose to ignore the risk.
You are wrong in concluding that "it was working in IFORT but failed in IFX". A program that does not produce error messages is not necessarily a correct program.
Here is a short program to drive home my points. Run it four times (i) ifort /Od, (ii) ifort /O2, (iii) ifx /Od and (iv) ifx /O2. Compare the results. My challenge to you: Which of those four runs is "correct" and what is your justification for your selection?
! demonstrate risk of assuming short circuit evaluation
program shCircBool
implicit none
integer :: ij(1) = [1]
integer k
call sub(ij,1,k)
print *,'2 ',k
end program
subroutine sub(ij,n,k)
implicit none
integer n,ij(n),k
k = -1
if(n.gt.1.or.ij(n+1).gt.0)k=1
return
end subroutine
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I wrote about this topic 25 years ago! Doctor Fortran and "The Dog that Did Not Bark" - Doctor Fortran (stevelionel.com)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Ah, that is the one! I could not find it before, when I posted my reply :).
