Re: Is this a compiler error?



Michael Trover <mtrover@xxxxxxxxxxxxx> wrote:

[an incomplete example]

Little can be concluded from the excerpt you showed. We would need to
actually see the functions - not just a description of their interface.
Yes, it matters. A lot.

As is, we have no guarantee that the code is even valid Fortran at all.
There are many things that you could do in the functions that would make
the code invalid in ways that might not be obvious to you. Function side
effects are *VERY* high on that list. WIthout seeing more data, that
would be my guess as to what might be happening, but that depends very
much on the functions, which you didn't show.

Isn't Fortran suppose to be associative and commutative?

No. Those words don't even appear in the Fortran standard. (I just
grepped the source of the f2003 standard to make sure I was telling the
truth). So you'd first have to very precisely define exactly what you
meant in the context of a programming language. No the definitions you
learned in grade school arithmetic are not sufficient to directly apply
to programming languages.

As for associative, absolutely *NO* *NO* *NO*. Finite precision floating
point arithmetic is never associative. That's not a language matter;
that's computer hardware.

There has also been hardware that was not commutative for some basic
arithmetic operations. I forget the details, and it was an oddball case,
but such have existed.

At a higher level, which does get into language issues, it is up to you,
the programmer, to write your functions in such a way that their side
effects don't cause "oddities". In most cases of oddities like the one
you show the code is technically illegal Fortran, but illegal in a way
that compilers don't tend to catch for you. Failing to catch such things
is not a compiler bug; the standard doesn't require it, and it is often
impractical for a compiler to do.

Using PURE functions greatly increases the odds of the compiler catching
things like that. Unfortunately, PURE functions are so limitted that
many things can't be done with them. For example, you can't have
diagnostic output in them.

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



Relevant Pages

  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: Is this a compiler error?
    ... we have no guarantee that the code is even valid Fortran at all. ... Those words don't even appear in the Fortran standard. ... |> meant in the context of a programming language. ... |> impractical for a compiler to do. ...
    (comp.lang.fortran)
  • Re: Bugs at my web site
    ... what might prove fatal with a new compiler. ... that I think they are good traditional fortran, whatever some standard might ... I hope the g95 people, after taking a good long vacation to ...
    (comp.lang.fortran)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
  • Re: Starting to doubt fortran
    ... that there were absolutely no "clever" tricks. ... time a new version of the vendors C compiler comes out. ... Fortran), it could be reliably depended upon in a portable way. ... That's beyond the standard, but many tend to be so ...
    (comp.lang.fortran)