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.
