Do loop with HUGE stepsize
Thomas Koenig
Is this program valid?
program main
implicit none
integer:: i, n, huge
data huge /z'7fffffff'/
n = 0
do 100 i=0,1,huge
n = n + 1
100 continue
print *,n
end
Please assume that the integer value huge does indeed represent the
biggest positive integer (I just wrote it this way because I also
wanted to throw it at g77, which doesn't have the HUGE intrinsic).
Myself, I don't think the program is valid, because the nuber
of iterations per 8.1.6.4.1 in 04-007.pdf would then be (1 - 0 +
huge(0))/huge(0), which overflows and is therefore invalid.
The reason I'm asking is that gfortran currently generates less then
optimal code for do loops with non-unity or unknown step size in order
to execute cases like the one above "correctly". I would like to change
that behavior, but I'd like some feedback from c.l.f before I do so.
Current status is that g77 prints 0 and gfortran prints 1.
m_b_metcalf
The standard would not appear to require that the expression you quote
is actually used. It says that the number of iterations is
'established' (a weasel word) and so it is not necessarily calculated.
I would expect an implemention simply to do what is expected for this
loop: to perform one iteration and print '1'.
Regards,
Mike Metcalf
Richard Maine
> Is this program valid?
>
> program main
> implicit none
> integer:: i, n, huge
> data huge /z'7fffffff'/
>
> n = 0
> do 100 i=0,1,huge
> n = n + 1
> 100 continue
> print *,n
> end
>
> Please assume that the integer value huge does indeed represent the
> biggest positive integer (I just wrote it this way because I also
> wanted to throw it at g77, which doesn't have the HUGE intrinsic).
>
> Myself, I don't think the program is valid, because the nuber
> of iterations per 8.1.6.4.1 in 04-007.pdf would then be (1 - 0 +
> huge(0))/huge(0), which overflows and is therefore invalid.
I'd say it was procesor dependent. The standard gives compilers
considerable leeway in evaluating expressions. That includes leeway
having to do with rearrangement and with things like overflow.
So if you want to treat it as invalid, I don't think a standards
conformance argument could be made against you. Quality of
implementation arguments are a separate matter.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
robin
| Hello world,
|
| Is this program valid?
|
| program main
| implicit none
| integer:: i, n, huge
| data huge /z'7fffffff'/
|
| n = 0
| do 100 i=0,1,huge
| n = n + 1
| 100 continue
| print *,n
| end
|
| Please assume that the integer value huge does indeed represent the
| biggest positive integer (I just wrote it this way because I also
| wanted to throw it at g77, which doesn't have the HUGE intrinsic).
|
| Myself, I don't think the program is valid, because the nuber
| of iterations per 8.1.6.4.1 in 04-007.pdf would then be (1 - 0 +
| huge(0))/huge(0), which overflows and is therefore invalid.
That is a paper formula that tells you kow many times the loop is executed.
It is mainly useful when the control variable is REAL.
| The reason I'm asking is that gfortran currently generates less then
| optimal code for do loops with non-unity or unknown step size in order
| to execute cases like the one above "correctly". I would like to change
| that behavior, but I'd like some feedback from c.l.f before I do so.
What you are overlooking is the fact that HUGE here is a variable,
not a constant. Because it is a variable, the iteration count
has to be determined at run time, whereas with the HUGE intrinsic,
the increment is a constant, and therefore the iteration count can be determined
at compilation time. In your code here, for the interation count
to be computed properly, double precision integer arithmetic must be used,
otherwise overflow occurs. (alternatively, two tests could be used :
one for a positive increment, the other for a negative increment).
| Current status is that g77 prints 0 and gfortran prints 1.
The loop is valid, and should be executed exactly once.
To determine whether the loop is entered, i is set to 0 and compared with 1.
Since 0 < 1, the loop therefore is entered.
At the end of one iteration, i is incremented; thus 0+huge(0)
yields huge(0), which is compared with 1, and thus the
loop terminates. At no stage can overflow occur.
If that doesn't happen, the compiler has a bug.
robin
| Thomas Koenig <tko...@netcologne.de> wrote:
|
| > Is this program valid?
| >
| > program main
| > implicit none
| > integer:: i, n, huge
| > data huge /z'7fffffff'/
| >
| > n = 0
| > do 100 i=0,1,huge
| > n = n + 1
| > 100 continue
| > print *,n
| > end
| >
| > Please assume that the integer value huge does indeed represent the
| > biggest positive integer (I just wrote it this way because I also
| > wanted to throw it at g77, which doesn't have the HUGE intrinsic).
| >
| > Myself, I don't think the program is valid, because the nuber
| > of iterations per 8.1.6.4.1 in 04-007.pdf would then be (1 - 0 +
| > huge(0))/huge(0), which overflows and is therefore invalid.
|
| I'd say it was procesor dependent. The standard gives compilers
| considerable leeway in evaluating expressions. That includes leeway
| having to do with rearrangement and with things like overflow.
|
| So if you want to treat it as invalid, I don't think a standards
| conformance argument could be made against you. Quality of
| implementation arguments are a separate matter.
It is neither "processor dependent" nor "quality of implementation".
It's a compiler bug.
The loop is a valid piece of code. Overflow doesn't come into it.
Not to execute the loop body - and without warning - is an error.
FX
> with 1. Since 0 < 1, the loop therefore is entered. At the end of one
> iteration, i is incremented; thus 0+huge(0) yields huge(0), which is
> compared with 1, and thus the loop terminates. At no stage can
> overflow occur.
This is your own internal view of how loops should be handled. I don't
believe the standard has wording along these lines.
Or, said in a different manner: your post has no reference to (the / any)
Fortran standard, hence it is irrelevant to the discussion.
--
FX
nm...@cam.ac.uk
I agree. 8.1.6.4.1 paragraph 1 says that 0, 1 and huge are evaluated
and converted to the KIND of i. If there were an overflow there, the
program would be invalid - end of story.
But paragraph 2 says "The iteration count is established and is the
value of the expression (m2 -m1 +m3)/m3, unless that value is negative,
in which case the iteration count is 0." And the standard uses the
word "establish" for actions where it means "the processor does this,
but don't ask how - it just does". As you know - you edited it!
I think that it's an ambiguity in the standard, but not one that is
important enough to worry about.
Regards,
Nick Maclaren.
glen herrmannsfeldt
> In article <1j9krn8.fow2421771blcN%nos...@see.signature>,
> Richard Maine <nos...@see.signature> wrote:
>>I'd say it was procesor dependent. The standard gives compilers
>>considerable leeway in evaluating expressions. That includes leeway
>>having to do with rearrangement and with things like overflow.
>>So if you want to treat it as invalid, I don't think a standards
>>conformance argument could be made against you. Quality of
>>implementation arguments are a separate matter.
> I agree. 8.1.6.4.1 paragraph 1 says that 0, 1 and huge are evaluated
> and converted to the KIND of i. If there were an overflow there, the
> program would be invalid - end of story.
> But paragraph 2 says "The iteration count is established and is the
> value of the expression (m2 -m1 +m3)/m3, unless that value is negative,
> in which case the iteration count is 0." And the standard uses the
> word "establish" for actions where it means "the processor does this,
> but don't ask how - it just does". As you know - you edited it!
Richard will complain, but I sometimes look at the possible
implementations when trying to understand why things are the
way they are. Many features of the standard are designed around
the possibility, or lack thereof, of a good implementation.
In the case of DO loops with constant m3, it is convenient to
generate an ordinary initialize, compare with conditional branch,
with increment at the end. Some processors have special instructions
to make that easier, others don't. One can also do it computing
the expression above, using a loop construct to count the iterations,
and separately updating the DO variable. The latter is especially
convenient on processors with decrement and conditional branch
as one instruction. It might be that some can compute the given
expression with unsigned arithmetic (available to the compiler
if not the programmer).
With variable m3, it gets more interesting. Computing the
expression as given, and following the latter method above,
seems more likely than in the constant case. In the case of
loops with fairly simple content, one can also generate two
separate loops, with different conditional branches and choose
the appropriate loop based on the sign of m3.
> I think that it's an ambiguity in the standard, but not one that is
> important enough to worry about.
Likely to cause more problems is the case when m2 is HUGE.
In that case, signed tests for greater than fail.
-- glen
robin
|> To determine whether the loop is entered, i is set to 0 and compared
| > with 1. Since 0 < 1, the loop therefore is entered. At the end of one
| > iteration, i is incremented; thus 0+huge(0) yields huge(0), which is
| > compared with 1, and thus the loop terminates. At no stage can
| > overflow occur.
|
| This is your own internal view of how loops should be handled. I don't
| believe the standard has wording along these lines.
It's how loops are actually and typically implented.
| Or, said in a different manner: your post has no reference to (the / any)
| Fortran standard, hence it is irrelevant to the discussion.
It's perfectly relevant. The standard gives a formula
as to the number of iterations. This is to clarify things for the
reader. It doesn't state what the machine instructions must do.
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>"FX" <cou...@alussinan.org> wrote in message news:hee2mm$qr0$1...@nef.ens.fr...
>
>| Fortran standard, hence it is irrelevant to the discussion.
>
>It's perfectly relevant. The standard gives a formula
>as to the number of iterations. This is to clarify things for the
>reader. It doesn't state what the machine instructions must do.
Let it be recorded that I do not always disagree with "robin".
That is precisely correct, and the word "established" makes it
clear that it is the intent.
Regards,
Nick Maclaren.