topic Thanks for the info. in Intel® Fortran Compiler

warning on implicit type conversion

MR — Tue, 12 May 2009 10:55:48 GMT

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

Re: warning on implicit type conversion

Steven_L_Intel1 — Tue, 12 May 2009 12:59:42 GMT

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.

Re: warning on implicit type conversion

jimdempseyatthecove — Tue, 12 May 2009 20:44:51 GMT

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

Re: warning on implicit type conversion

Steven_L_Intel1 — Wed, 13 May 2009 12:25:27 GMT

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.

Re: warning on implicit type conversion

jimdempseyatthecove — Wed, 13 May 2009 20:17:46 GMT

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

Re: warning on implicit type conversion

Steven_L_Intel1 — Thu, 14 May 2009 13:40:07 GMT

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.

Re: warning on implicit type conversion

jimdempseyatthecove — Thu, 14 May 2009 20:19:04 GMT

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

Re: warning on implicit type conversion

Steven_L_Intel1 — Thu, 14 May 2009 20:24:45 GMT

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.

Quote:Steve Lionel (Intel)

Øyvind_J_ — Thu, 21 Jan 2016 12:19:38 GMT

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

This suggestion is not

Steven_L_Intel1 — Thu, 21 Jan 2016 15:31:01 GMT

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

Thanks for the info.

Øyvind_J_ — Fri, 29 Jan 2016 09:12:11 GMT

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

Would you want this warning

Steven_L_Intel1 — Fri, 29 Jan 2016 15:25:34 GMT

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.

For me, an option would be

jimdempseyatthecove — Fri, 29 Jan 2016 16:42:32 GMT

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