- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
In a fortran code I wrote (schematically, I cant copy the origin code to here) there is the following if condition inside a loop. The variable in the if condition (ic) defined in a common block and its value set in other subroutine:
Do i=1, n
.
xx = 1
if (ic .eq.1) then
xx = .
endif
.
enddo
When I used ifort version 9.0.032 with O3 optimization, it dosnt enter to the if block so xx remains equal to one. I looked at the opt-report output and according to this report:
Condition at line 591 hoisted from loop at line 589 referring to those lines.
When I used ifort version 9.1.033 it was enter to the if block. This is the correct action. It wasnt hoisted the condition according to the opt-report.
What is the explanation to this phenomena? Is there a problem with version 9.0.32 which was fixed in version 9.1.033? what should I do to avoid such problems in the future? currently I dont have access to newer versions.
Thanks,
Oren
In a fortran code I wrote (schematically, I cant copy the origin code to here) there is the following if condition inside a loop. The variable in the if condition (ic) defined in a common block and its value set in other subroutine:
Do i=1, n
.
xx = 1
if (ic .eq.1) then
xx = .
endif
.
enddo
When I used ifort version 9.0.032 with O3 optimization, it dosnt enter to the if block so xx remains equal to one. I looked at the opt-report output and according to this report:
Condition at line 591 hoisted from loop at line 589 referring to those lines.
When I used ifort version 9.1.033 it was enter to the if block. This is the correct action. It wasnt hoisted the condition according to the opt-report.
What is the explanation to this phenomena? Is there a problem with version 9.0.32 which was fixed in version 9.1.033? what should I do to avoid such problems in the future? currently I dont have access to newer versions.
Thanks,
Oren
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A compiler might reasonably replace such a simple IF by a conditional move. If it could assure that the condition is loop invariant, it could be expected to hoist the condition outside the loop. Without some specifics, we can't see the nature of your problem.

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