Fortran - Floating point crash due to implicit

Author

Floating point crash due to implicit

Chris Theis

2005-12-05, 7:04 pm

Hello,

today I've stumbled over the following problem where probably some of you
could shed some light on why this happens. I've been using GNU's FORTRAN 77
and in some 3rd party code I have the following statement:

IMPLICIT DOUBLE PRECISION (A-H, O-Z)

in the part of the code which I added the idea was that I would call a
function called PARTID, which would expect an integer and return an integer
variable.

PartType = PARTID( I )

and the function would look like:

INTEGER FUNCTION PARTID( PDG_ID )
INTEGER PDG_ID

PARTID = 2 * PDG_ID
END

When I ran that code the program would crash with a "floating point
exception" at the call to PARTID. I finally realized that PARTID must have
been declared as double precision by the implicit statement and I kind of
did a redeclaration with my function. After exchanging the INTEGER
declaration with DOUBLE PRECISION everything worked smoothly. Could somebody
explain to my what happened here on a compiler level and why the compiler
did not (or could not?) show some kind of diagnostic warning. I would have
assumed that the conversion from integer to double should (even if performed
implicitely) not cause this problem.

Thanks
Chris

Michael Wild

2005-12-05, 7:04 pm

Hi

I'm not the guru, but here's what I know:

The IMPLICIT statement tells the compiler, that names (variables and
functions) beginning with A-H and O-Z are considered to be double
precission. Since F77 does not use explicit interfaces and if you do
separate compilation, the compiler has no way to do type checking and
just assumes that what you tell it in the code is correct. So it just
interpreted PARTID as a double precission function.

The thing to do is declaring PARTID as INTEGER and EXTERNAL in the code
calling PARTID. This will override the IMPLICIT statement.

Hope this helps

- Michael

Richard Maine

2005-12-05, 7:04 pm

Chris Theis <christian.theis@nospam.cern.ch> wrote:

> IMPLICIT DOUBLE PRECISION (A-H, O-Z)

> I finally realized that PARTID must have
> been declared as double precision by the implicit statement

Yes.

> and I kind of did a redeclaration with my function.

No. You declared it, but you did not *RE*declare it. The type of a
function has to be known in 2 places - in the function itself and in
wherever the function is invoked from. Those 2 places are independent.
They could be in separate files and compiled at separate times. In f77,
there is no way for one place to get information from the other - you
just have to declare the appropriate type in both places.

> Could somebody
> explain to my what happened here on a compiler level and why the compiler
> did not (or could not?) show some kind of diagnostic warning.

How could it know? The function is fine - it is fine to have a function
that returns an integer. The calling program is also fine when looked at
separately. It is fine to have a function that returns a double
precision, as you have implicitly told it. The function doesn't actually
return a double, but the compiler has no way of knowing that you've lied
to it, as it doesn't "see" the function at the same time.

> I would have
> assumed that the conversion from integer to double should (even if performed
> implicitely) not cause this problem.

There is no such conversion here. You have a function that returns an
integer. You have told the main program (implicitly, but it makes no
difference whether it is implicit or explicit) that the function returns
a double. This does *NOT* say to take the integer result and convert it
to double. You are telling the main program that what the function
returns is already a double. Since it isn't, havoc results. It will
interpret the returned bits as a double. Since integer and double aren't
even the same size, I'm not even sure exactly what bits will get so
interpreted, but anyway, it will interpret something as a double.

Fortran 90 has ways for the declarations in a function to automatically
get communicated to the caller so that you don't have to repeat them
there. (One way is to put the function in a module and then use the
module in the main program). Fortran 77 doesn't. It is important to
understand that the f77 model is that each procedure gets compiled
completely separately, without looking at any others. Now optimizing
compilers might sometimes look at multiple procedures together, and
occasionally compilers will notice errors like this (particularly if
everything is in the same file), but in general you can't count on it.

I'll skip the lecture about suggesting the use of "implicit none", which
would have caught this error.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Ron Shepard

2005-12-05, 7:04 pm

In article <dn1oua$etf$1@sunnews.cern.ch>,
"Chris Theis" <christian.theis@nospam.cern.ch> wrote:

> IMPLICIT DOUBLE PRECISION (A-H, O-Z)
>
> in the part of the code which I added the idea was that I would call a
> function called PARTID, which would expect an integer and return an integer
> variable.

The external function has a type in the calling program. That type
can be explicitly or implicitly declared, but it must match the
actual type of the function. If the declarations don't match, then
your illegal code can do anything it wants (dump core, start WWIII,
invade Iraq, etc.).

F90 and later introduce some additional aspects of function
declaration (implicit and explicit interfaces, module scope,
internal functions, generic interfaces, etc.).

$.02 -Ron Shepard

Chris Theis

2005-12-07, 4:01 am

"Richard Maine" <nospam@see.signature> wrote in message
news:1h73b6c.1vlrivq1rcxcnnN%nospam@see.signature...
> Chris Theis <christian.theis@nospam.cern.ch> wrote:
>
[SNIP]

Thanks for the informative explanation!

> I'll skip the lecture about suggesting the use of "implicit none", which
> would have caught this error.

Well, with me you're running into open doors, but that code was not under my
control.

Cheers
Chris

Sponsored Links