flag to force float division when the lvalue is a float

[nooj]

Several times now I have been bitten by the bug that ifort always performs integer division, even if the destination variable is a real. I'd like a flag to change this behavior.

I know I could always use "d0" or something, but I'm also column-limited, so I don't. And once in a while, something slips through unnoticed. When it does (partly because it's so rare) it takes days of checking and winnowing down posibilities until I finally find it. The error almost always slips through when I evaluate a polynomial expression at integer values (ie, the data type of array indices). To know that I wasted four critical days due to a simple miscommunication between me and the compiler is inordinately frustrating.

If I wanted an integer, I'd've stored the result in an integer. I put it in a real because I wanted a real.

Thank you for listening.

- Nooj

[mecej4]

If I am not mistaken, what you want is for the program

[fortran]program tst
integer :: i=5,j=4
real :: x
x=i/j
write(*,*)i,j,x
end program tst
[/fortran]

to produce the output

[bash]           5           3   1.2500000[/bash]

rather than the correct output

[bash]           5           3   1.0000000[/bash]

The rules of Fortran are quite clear. Expressions have types, and the rules for determining the type of a mixed-type expression are spelled out in detail. When an expression is assigned to a variable of a different type, a type conversion is made if needed. The value of the expression is independent of the type of the variable to which the value is to be assigned.

For similar reasons, replacing the expression 'i/j' by 'real(i/j)' in the program above is not going to change the result.

Thus, your complaint is against Fortran, rather than the Intel compiler. In other words, the behavior that you call a 'bug' is required by the Fortran Standard, and you will probably find all Fortran compilers featuring the same perceived 'bug'. Since billions of programs exist that adhere to and, furthermore, depend on the semantics specified in the language standards, what you ask for is not reasonable.

The situation is quite similar in C, as well:

[cpp]#include 
int main(){
int i=5,j=4; float x=i/j;
printf("%d %d %fn",i,j,x);
}
[/cpp]

produces

[bash]5 4 1.000000[/bash]

Few compiler vendors will implement a flag to provide standard-violating semantics.

[nooj]

> what you ask for is not reasonable

everything you said is correct. what i really want is a flag to report implicit type conversion, as discussed in this thread: http://software.intel.com/en-us/forums/showthread.php?t=65514 (see the last two posts for a summary).

in that thread, steve lionel reports that he suggested flags to warn of implicit type conversion and implicit kind conversion.

so i have two questions: does the situation that steve and jim dempsey discussed in that thread cover my situation? and what is the status of the suggestions? i do not see reference to type conversion warnings in the ifort man page.

-nooj

[mecej4]

"what i really want is a flag to report implicit type conversion" -- that is totally different from what was first demanded (and the thread title, as well), and most people would be happy to see warnings for such statements, say "warning -- integer expression assigned to integer; risk of truncation from integer division".

I do not think that current documentation describes as-yet-unimplemented compiler flags, and, if Intel implements this warning, we will not see it until Release 11.7 (August?) or Release 12 (end of 2010?).

[jimdempseyatthecove]

The problem with a flag to issue a warning for type conversion is it will also catch

real :: array(N)
...
do i=1,N
array(i) = i
end do

In my experience (limited as it may be) you will receive 10,000 warnings like above for every 1 warning that might be meaningful (catch an errant conversion). From my view point the option would be for all purposes useless due to the inordinate number of false positives.

FORTRAN has since inception, a policy of autoconversion from integer to real and real to integer with specific conversion rules.

C++ on the other hand is "strongly typed" and thus will report warning on auto conversions.

You will not be able to change the behavior.

Jim Dempsey

[mecej4]

"..you will receive 10,000 warnings like above for every 1 warning that might be meaningful..": very true! There is always a tussle between giving so many warnings that none get read, and not giving 'essential' warnings.

That is why one hopes that one's compiler allows turning off, at the user's wish, (i) a specific numbered warning, (ii) a range of numbered warnings, (iii) all warnings beyond an upper limit on the number of warnings of all types, (iv) all warnings. Once one recognizes (as 'nooj' did) one's own frequent coding weaknesses, the specific warnings to show are known and can be specified in the compiler's configuration file.

[nooj]

> > what i really want is a flag to report implicit type conversion
> that is totally different from what was first demanded (and the thread title, as well)

yes, live and learn. and if jim's comments are any indication, that's not really what i want anyway.
perhaps what i really really want is to add another layer of organization and baseline testing in my code development, so that these errors occur less often.


off topic: jim, you rewrote some code for me over a year ago (http://software.intel.com/en-us/forums/showthread.php?t=62349, reply 12), and i just now managed to actually post a reply. (i kept getting weird errors, and couldn't figure out how to send you a personal message.) anyway, thank you. it was the easiest, best speedup improvement i've had, and i'm still reaping the benefits from it!

- nooj

[jimdempseyatthecove]

nooj,

I am glad it worked out. (sorry you had to debug the code)
What was the speed-up by the way?

you can reach me at

jim(at sign)quickthreadprogramming.com

I have a series of articles in the queue to be posted on the ISN Blogs section (link at top of this page) dealing with the parallelization of large matrix multiplication (where yours was small matrix multiplication).You might be interested in reading it (assuming it gets out of the queue and gets posted).

The layout of the post is a bit different from most blogposts (but might be similar to the n-Body articles), where I showthe reader the steps involved in converting a serial algorithm into a well written parallel algorithm. If you can absorbe the thinking process behind the optimizations instead of concentrating on the final program, you will have adopted a skill set of observation and analysiswhich will help you on other parallelization situations.

Jim Dempsey