warning on implicit type conversion

[MR]

Dear all,
this is maybe an obvious question, but I can't find the answer. Is
there an option in ifort to issue a warning on implicit type
conversions? I am mostly interested in REAL to DOUBLE PRECISION and
INTEGER to REAL conversions (as -Wconversion in gfortran).

Thank you,
Marco

[Steven_L_Intel1]

Intel Fortran does not have such an option, but I think it would be a good idea. I'll pass this on as a feature request.

[jimdempseyatthecove]

Quoting - Steve Lionel (Intel)

Intel Fortran does not have such an option, but I think it would be a good idea. I'll pass this on as a feature request.

Steve,

If (when) they look at adding the warning for implicit conversions, have them add an option or level number to detect and warn for mixed use of literals. e.g. using a real(4) literal in a real(8) IF statement. Sometimes thows will bite you (and you won't notice the error when looking at the code). Same with DO loop mixed mode variables.

Jim Dempsey

[Steven_L_Intel1]

Jim,

I did suggest a separate option for warning about implicit kind conversions. I will note that Intel Fortran goes further than the standard requires in performing implicit conversions, such as between LOGICAL and numeric types, and that enabling standards checking will catch such uses.

[jimdempseyatthecove]

Steve,

will the standards checking catch


if(aReal8Var .eq. 1.1)

probably not.

The compiler will generate a REAL(4) constant, load it, then convert to REAL(8)

There are two issues with this, well three issues. 1) This is fine to do this using the standards (not complaining about the standards). 2) non-optimal code is generated, using 1.0_8 will produce optimal code. 3) unexpected results may occure when implicit conversion modifies small parts of the fraction (or to rephrase, generating a fraction not intended due to oversight in not specifying _8 on the literal constant).

I do not expect the standards to be changed. But it would be nice to have the compiler, under direction of option switch,detect and report on this. Same to when generating code paths that produce temporary array descriptors.

Detecting and correcting for these issues (problems) at compile time is much prefered than requiring discovery during debug time.

Jim Dempsey

[Steven_L_Intel1]

No, standards checking won't catch that because it is standard-conforming. I didn't intend to claim that it would. It will catch something like:

if (X) ...

where X is REAL.

[jimdempseyatthecove]

The suggestion was not to catch violations of standards conformance (as this is expected of the compiler).

The suggestion is as a programming aid in isolating standards conforming statements that may produce resultscounter to those intended as well as performance related hints.

if(X .eq. 1) ...
where X is REAL

A standards conformance compiler will load 1 as an integer, then convert from integer to REAL then test. Not optimal.

if(X .eq. 1.1) ...
where X is REAL(8)

A standards conformance compiler will load 1.1 as a REAL(4), then convert from REAL(4) to REAL(8) then test. Not optimal and also is not equivilent to

if(X .eq. 1.1_8) ...
where X is REAL(8)

Since the values being compared are different.

I remember taking a few week walking through code on a converson effort. Had there been an option switch to say report questionable use of mixed variables then the time lost may have been reduced to under a day.

Jim Dempsey

[Steven_L_Intel1]

I got that. There are two different requests here, one to warn on implicit type conversion and one to warn on implicit kind conversion. I have suggested both. My mention of standards checking was to note that the compiler can detect some kinds of implicit type conversion that are non-standard, such as real to logical.

[Øyvind_J_]

Steve Lionel (Intel) wrote:

I got that. There are two different requests here, one to warn on implicit type conversion and one to warn on implicit kind conversion. I have suggested both. [...]

What is the status of the feature requests? Will these warnings be implemented?

Øyvind

[Steven_L_Intel1]

This suggestion is not currently scheduled for implementation. It may happen in the future.

[Øyvind_J_]

Thanks for the info.

I would also find the warning flags useful, especially the kind conversion warning. Every now and then I have to hunt down the reason why our calculations loose precision. Sometimes this is because a REAL(4) has found its way into an expression of REAL(8)s, other times the reason is more subtle. I think the warning flag could save me a lot of time in these situations.

Øyvind

[Steven_L_Intel1]

Would you want this warning on by default or would it be ok if it were optional? My guess is that if we turned it on by default, the torches and pitchforks would be at our door in short order.

[jimdempseyatthecove]

For me, an option would be best. Together with adding

!DIR$ OPTIONS /WARN=[NO]PROMOTION

Or something like that.

Another related option that might be handy is when a literal is expressed to significantly higher precision than that will be used.

An example of this is using a REAL(4) literal for PI containing 20 decimal places.

Essentially what is being asked of the compiler is to have an option that will produce warnings whenever the code generated appears to be in conflict to how the code was written. (as subjective as this is)

Jim Dempsey