Hello,

I just ran into an odd portability problem:

program printpi
real, parameter :: pi = 4.0*atan(1.0)
write(*,*) pi
end program

This simple program fails with the CVF and Intel compiler, but g95
allows
the use of atan() here.

This raises two questions:
- Are functions like atan() not allowed?
- Which functions _are_ allowed?

It seems counter-intuitive, as the expression above has a perfectly
simple
interpretation and can be evaluated at compile time. Though I realise I
may
be naive in these matters ;).

Regards,

Arjen

Arjen Markus wrote:

Nope, functions like atan() are not allowed. At least, not in Fortran
95 -- the only elemental intrinsic functions allowed are the ones that
are of type integer or character (and where each argument is of type
integer or character). No floating-point.

Brooks Moses schreef:

Brooks Moses wrote:

(snip)

Many compilers do software floating point constant expression
evaluation. This was interesting when the pentium FDIV bug came
out, and a test program using constants showed no bug.

I don't know how many do atan() separate from the run time atan()
routine.

-- glen

I think Brooks didn't say it was impossible, but only stated a reason why
there is more difficult in implementing it than meet most eyes.

I think any compiler that is capable of cross-compiling has to do in a
host-independent way. For example, gfortran uses MPFR for many such
compile-time evaluations of real constants.

Nothing else makes sense, anyway. What about initialization expressions that
don't rely on intrinsics, such as exponentiation? It also isn't restricted
to FP - the target could support integer or character kinds not natively
supported on the host.

People realised that it was onerous not to be able to use these intrinsics
in these places, and that it was (no longer, perhaps) onerous to support them
in the compiler properly.

I'll betcha that the restriction was already contentious when F90/F95 were
being defined. I'm surprised that CVF didn't support this as an extension.
Steve?

Jan

Arjen Markus wrote:

<robert.corbett@sun.com> wrote:

Or, more obviously, there is the case of cross-compilation. The target
machine might not even have the same floating-point representation as
the compilation machine. In that case, you'd have had to emulate not
only the math library, but even fundamental floating-point operations.
That would have increased the required size of the compiler even more.
Yes, cross-compilation was a significant issue.

Arjen Markus wrote:

That basically doesn't "work". Too many things can depend on
initialization expresssions. If you start saying that initialization
expressions can be put off until start-up of the program, before long
you've basically moved the whole compiler into run-time. You have
basically destroyed the concept of compilation as a separate step. You
have something more like.... I think it is often called just-in-time
compilation or some such thing. While that can be done in principle, and
is done in some imlementations of some languages (Java?), that's *NOT* a
way to keep the target execution environment small. It simply was not an
option in the environments and days in question.

Arjen Markus wrote:

I used to see, though not for a while now:

DATA PI/0./
IF(PI.EQ.0) PI=4.*ATAN(1.0)

It would then be initialized once (assuming a static
variable). The result would be the same even if it
was initialized each time.

-- glen