The issue is related to the following loop:
do while ( ( cnt /= idx ) .and. iterate( this, val ) )
cnt = cnt + 1
enddo
GFortran is short circuiting on the first conditional and thus does not run the last iterate, while IFort and CrayFTN do run the last iterate. Simple reordering of the loop gives the desired effect:
do while ( cnt /= idx )
if (.not. iterate( this, val )) exit
cnt = cnt + 1
enddo
A memleak results from this using IFort 11.1. Haven't looked at teh remaining 4 lines in the routine yet to see what's different....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't remember the details of the BlockIt/PyF95++ implementation, but my experience with the 11.1 Intel compiler series is that a lot of the new F2003 features which are "implemented" are still quite buggy. I would recomend upgrading to 12.x if you have the opportunity to do so. If the BlockIt/PyF95++ implementation requires the finalize language feature there may be issues with this in Intel's implementation. (This I haven't checked, so this is just and unconfirmed hunch.)
Also, a note on DO WHILE from 'Modern Fortran Explained' by Metcalf, Reid & Cohen:
"We prefer the [DO loop] form that uses the EXIT statement because this can be placed anywhere in a loop, whereas the DO WHILE statement always performs its test at the loop start. If the _scalar-logical-exp_ becomes false in the middle of the loop, the rest of the loop is still executed. Potential optimization penalties that the use of the DO WHILE entails are fully described in chapter 10 of 'Optimizing Super Compilers for Super Computers,' M. Wolfe (Pitman, 1989)."
I tend to agree, and think that stylistically this is better and less prone to bugs. (Using exit statements inside the loops.)
Just my 2 cents. Keep up the great work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the references. It was an easy oversight in the original code that just never was noticed. I've been pushing to get 12.x since I discovered a few other issues....
I personally like the `do while` for conditionals like integer to integer comparison. I do agree it tends to work out a little better if complex conditionals are built up inside the loop with appropriate exits. In this case I think it is much cleaner since the integer looping is just a counter and is the true conditional while the second part of the original conditional is now inside the loop and is the explicit "action" that the loop performs to get the return value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another, albeit quite picky, stylistic comment is that I think `enddo` is less legible than `end do` for what its worth. I don't know what editor/IDE you use, but Emacs these days has some nice auto-completion of code blocks, keyword upcasing etc. These comments are by no means meant to be criticism, just sharing a tip/opinion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue is related to the following loop:
do while ( ( cnt /= idx ) .and. iterate( this, val ) )
cnt = cnt + 1
enddo
GFortran is short circuiting on the first conditional and thus does not run the last iterate, while IFort and CrayFTN do run the last iterate. Simple reordering of the loop gives the desired effect:
do while ( cnt /= idx )
if (.not. iterate( this, val )) exit
cnt = cnt + 1
enddo
A memleak results from this using IFort 11.1. Haven't looked at teh remaining 4 lines in the routine yet to see what's different....
I don't remember the details of the BlockIt/PyF95++ implementation, but my experience with the 11.1 Intel compiler series is that a lot of the new F2003 features which are "implemented" are still quite buggy. I would recomend upgrading to 12.x if you have the opportunity to do so. If the BlockIt/PyF95++ implementation requires the finalize language feature there may be issues with this in Intel's implementation. (This I haven't checked, so this is just and unconfirmed hunch.)
Also, a note on DO WHILE from 'Modern Fortran Explained' by Metcalf, Reid & Cohen:
"We prefer the [DO loop] form that uses the EXIT statement because this can be placed anywhere in a loop, whereas the DO WHILE statement always performs its test at the loop start. If the _scalar-logical-exp_ becomes false in the middle of the loop, the rest of the loop is still executed. Potential optimization penalties that the use of the DO WHILE entails are fully described in chapter 10 of 'Optimizing Super Compilers for Super Computers,' M. Wolfe (Pitman, 1989)."
I tend to agree, and think that stylistically this is better and less prone to bugs. (Using exit statements inside the loops.)
Just my 2 cents. Keep up the great work!
Thanks for the references. It was an easy oversight in the original code that just never was noticed. I've been pushing to get 12.x since I discovered a few other issues....
I personally like the `do while` for conditionals like integer to integer comparison. I do agree it tends to work out a little better if complex conditionals are built up inside the loop with appropriate exits. In this case I think it is much cleaner since the integer looping is just a counter and is the true conditional while the second part of the original conditional is now inside the loop and is the explicit "action" that the loop performs to get the return value.
Fair enough. It looks more like C that way :-)
Another, albeit quite picky, stylistic comment is that I think `enddo` is less legible than `end do` for what its worth. I don't know what editor/IDE you use, but Emacs these days has some nice auto-completion of code blocks, keyword upcasing etc. These comments are by no means meant to be criticism, just sharing a tip/opinion.