[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-10-17 10:41:49 UTC ---
(In reply to comment #3)
> "7.1.5.2.4 Evaluation of numeric intrinsic operations"
> "The execution of any numeric operation whose result is not defined by the
> arithmetic used by the processor is prohibited."

(Note that "processor" in the standard refers to the combination of compiler,
libraries, operating system and hardware/CPU.)


> Hm, the arithmetic used by the processor specifies that HUGE(i) + 1 is -INF.

I think you mean -HUGE(i)-1. (That's at least the hardware part of the
"processor".)


> Does that mean the value after the loop should be the wrapped value?

Seems so - at least that is what one gets after "huge(i)+1" - at least if one
regards it as defined by the processor.


> From the sentence above I do not read that the standard requires a
> specific behavior, just that it prohibits undefined behavior.

The wording is a bit vague as it is a catch all phrase.

Well, to a certain extend it is undefined behaviour: It depends on the
"processor" whether it is valid or not.


> Which means this is similar to C implementation specific behavior?

I don't know the exact wording for this case in the C standard, but I assume
so.


> Does the standard require us to be consistent there then?  Currently GCC
> assumes signed overflow invokes undefined behavior.

I think it doesn't require (but permits) this consistency. (As the semantic
differs between C and Fortran it can't require it.) The standard only specifies
interoperability with the "companion processor" for variables and function
calls.


Thus, the question is mostly what can a user (reasonably) expect. Users
seemingly like to use HUGE in loop bounds (cf. also PR 40205). For real-world
code I could imagine some use like
  do i = 1, huge(i)
    ...
    if (cond) exit
  end do
But I am not sure whether any real-world code contains such algorithms. At
least the two codes I use don't.