compiler option -real-size 64 and ALOG10

[e745200]

I have a problem compiling programs which use intrinsinc function ALOG10(real4_variable) with the compiler option -real-size 64.

This is a tiny example, in which the compiler option is irrelevant, and nevertheless has a bad side-effect.
The argument for the intrinsic function is explicitely declared as REAL(4), and should not be promoted by the compiler option, which, instead should only affect the "default" REAL variables.

[bash]$ cat tlog10.f IMPLICIT NONE REAL(4) :: D INTEGER :: E D=100.E0 E=ALOG10(D) WRITE(*,*) D, E END
$ ifort -V -real-size 64 tlog10.f -o tlog10 && ./tlog10
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.4.191 Build 20110427
...
tlog10.f(5): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ALOG10]
E=ALOG10(D)
---------------^
tlog10.f(5): error #6404: This name does not have a type, and must have an explicit type. [ALOG10]
E=ALOG10(D)
--------^
compilation aborted for tlog10.f (code 1)

[/bash] When not using the option, it works fine :

[bash]$ ifort64 -V tlog10.f -o tlog10 && ./tlog10 Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.4.191 Build 20110427 ... 100.0000 2 [/bash]


I can solve my problem just using the generic name LOG10 instead of ALOG10, but I wonder why I get this behavior. Did I misunderstand the meaning of the -real-size compiler flag ?


Thanks in advance.

[mecej4]

Options such as -real-size=64 are like hammers. If you do not understand the scope and the effect of the option, the resulting behavior can be unexpected and confusing. Since this option is not covered by the Fortran standard, its effect is whatever the compiler authors considered to be most useful to their users.

The ALOG10 function is known to be of type default REAL. Typically, type promotion options leave untouched those variables whose kinds are explicitly declared.

The combination of IMPLICIT NONE, REAL(4), ALOG10 and -real-size=64 opens up so many ways of interpreting how the KIND promotion should be done that it is necessary to consider the governing rules very carefully.

Try using

REAL :: D

instead, if you must use -real-size=64. Better still, take the trouble of changing the code by specifying the correct KINDs in the sources.

[Anonymous66]

The function ALOG10expects an argument of thedefault real type. When the flag -real-size 64 is used, the default real type is changed to REAL(8), so ALOG10 expects an argument of type REAL(8).

In this case, you should use the generic function LOG10 rather than the specific function ALOG10.

[e745200]

@ mecej4

Thanks for your response, but I cannot agree with you.

I am not referring to the Fortran standard, but to the intel compiler documentation, where I find that :

1) The options -real-size 64 defines the kind of the default REAL variables. It does not promote the variables explicitely declared as REAL(4) to a different kind;

2) ALOG10 expects a REAL(4) argument and returns a REAL(4) value, then, in my examples, all the variables have a correct kind;

3) There is not any default REAL variable in my example program, which might be affected by the compiler option.

Given the results I get, I think there is a mismatch between the documentation and the actual behavior of the compiler.

What you suggested (using REAL :: D ) actually works, and this confirms my feeling that the documentation does not correspond to the compiler behavior.

Being concerned about using a typing not depending on the compiler options, I would avoid using default REAL variables.

[e745200]

@ Annalee
Thanks for your answer.

If this is the behavior of the compiler, then I think the documentation needs to be clarified.
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/lin/compiler_f/lref_for/source_files/rflog10.htm

So far it says that :

1) (in the table) ALOG10 expects a REAL(4) argument (not a default REAL), and returns a REAL(4) result (not a default REAL).

2) (note 2) "The setting of compiler options specifying real size can affect ALOG10, CLOG10, and LOG10.", that is in contradiction with the table. What is affected (the argument or the result, or both) is also unspecified.

If the kind is not fixed, I miss the rationale behind using a "specific" function instead of its generic counterpart.

Thanks.

[Steven_L_Intel1]

The problem here is that ALOG10 is defined by the standard as taking an argument of type "default real". If you change the type of default real, then that changes what ALOG10 accepts. In your example, you set default real to be REAL(8), but explicitly passed a REAL(4) argument, thus the error.

I agree that our documentation of this aspect of intrinsics is overly simplified and can be confusing.

If you use LOG10 instead of ALOG10, you should get the correct function used for the REAL(4) argument.

[e745200]

Thanks, Steve.

As I said in the first place, I am aware that using LOG10 would solve any problem.

Simply, after having read the documentation I was surprised by the actual behavior of the compiler.
I am glad that that it is compliant to the standard. Only, I would prefer not having to read BOTH the standard AND the compiler documentation (just to find a contradiction ...) for these things.

For sure using REAL(4) instead of REAL in the table explaining what the specific functions would expect as their arguments is highly misleading.

I have also found that even a constant written using the E exponent (i.e. 1.E10) is assumed to be "default REAL". This too is not said in the documentation, which reads instead :
( http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/lin/compiler_f/lref_for/source_files/rfcrealr.htm )
"The exponent letter E denotes a single-precision real (REAL(4)) constant, unless the optional kind parameter specifies otherwise. For example, -9.E2_8 is a double-precision constant (which can also be written as -9.D2)."

In reality, the compiler acts as :
"The exponent letter E denotes a DEFAULT real (REAL) constant, unless the optional kind parameter specifies otherwise. For example, -9.E2_8 is a double-precision constant (which can also be written as -9.D2)."

I think REAL(4) and REAL should be used more carefully in the documentation.
I mean REAL(4) as a fixed kind type, and REAL a type whose kind depends on the compiler options, which defaults (so far) to REAL(4). The two things seems different to me. Am I wrong ?

Thanks.

[TimP]

I think you have understood these issues correctly, as far as that is possible.
Fortran standards don't cover compiler options which change the implied data type, but such options shouldn't break code which was standard compliant with the default, at least not in a case such as you present.

[e745200]

Thanks , Tim .

I feel more confindent of my lonely neuron, now ... ;-D

I hope documentation people will make the documentation simpler and more consistent.
To their benefit, I would point out that even the note (1) to ALOG10 in the table I mentioned seems to be out of place: it says that ALOG10 "is treated like LOG10." That does not seem true, since LOG10 will always accept any kind of input, while ALOG10 does not, as also Steve Lionel pointed out above.

Thanks again to all.

[mecej4]

I think that, in order to make the documentation easy to read and correct, it should not attempt to cover the effects of -real-size options (and corresponding directives in the source code) in the main body of the description.

Rather, the effects of the options and directives, which are only of interest to a small number of users, should be described by a set of rules in a footnote or in a paragraph set in smaller type. My understanding is that the -real-size options exist mainly for the sake of compiling legacy code that may have run on machines (e.g. CDC, Cray, Univac, Burroughs, ..) with 60, 64, 36, etc. bit single-precision floating point.

Of course, if Intel has documentation writers of such extraordinary expository powers that they can pull off an all-in-one-explanation-for-everything, I would be delighted.

[jimdempseyatthecove]

>> it should not attempt to cover the effects of -real-size options

Excepting to the extent where the argument is to bedeclared as DEFAULT REAL, the documentation should not say REAL(4). Also, early on in the documentation, DEFAULT REAL should be clearly defined along with options that alterits definition.Once these rules are followed then you need not attempt to cover the effects of -real-size.

Jim Dempsey

[e745200]

Yes, Jim.
That's my opinion too. The documentation would be lighter and tighter at the same time.

It seem, instead, that someone thought that being REAL(4) the default "default REAL", it has to be used in the documentation in place of "default REAL" and then a footnote should explain that it is actually affected by the compiler option.
That's clumsy, noisy and prone to writing and reading errors.

And, should change the default "default REAL" in the future (let us say, to REAL(8)), the documentation should be entirely revisited ...

Thanks to all.