weird lahey bug

subroutine test
do j = 1,huge(0)
if (j > 10) stop
print *, j
enddo
stop
end


1
2
3
4
5
6
7
8
9
10
Program Completed
Press Enter to Continue.

subroutine test
if (0< huge(0)) print *, ' zero less than huge(0)'
do j = 0,huge(0)
if (j > 10) stop
print *, j
enddo
stop
end


zero less than huge(0)
Program Completed
Press Enter to Continue.

In other words, If I try to run the loop from 0 to huge(0) it never
enters the loop.

On Apr 16, 12:31*am, "analys...@hotmail.com" <analys...@hotmail.com>
wrote:
> * * * subroutine test
> * * * do j = 1,huge(0)
> * * * if (j > 10) stop
> * * * print *, j
> * * * enddo
> * * * stop
> * * * end
>
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> Program Completed
> Press Enter to Continue.
>
> * * * subroutine test
> * * * if (0< huge(0)) print *, ' zero less than huge(0)'
> * * * do j = 0,huge(0)
> * * * if (j > 10) stop
> * * * print *, j
> * * * enddo
> * * * stop
> * * * end
>
> *zero less than huge(0)
> Program Completed
> Press Enter to Continue.
>
> In other words, If I try to run the loop from 0 to huge(0) it never
> enters the loop.

Have you tried running this as a program?
i.e.,
program test

analyst41@hotmail.com <analyst41@hotmail.com> wrote:

(snip)
> subroutine test
> if (0< huge(0)) print *, ' zero less than huge(0)'
> do j = 0,huge(0)
> if (j > 10) stop
> print *, j
> enddo
> stop
> end

> zero less than huge(0)
> Program Completed
> Press Enter to Continue.

> In other words, If I try to run the loop from 0 to huge(0) it never
> enters the loop.

As far as I know, that is allowed.

The loop count, huge(0)-0+1, doesn't fit in the appropriate sized
variable.

You can also try

do j=huge(0)-10,huge(0)

which might also fail.

-- glen

On 4/15/2012 9:31 AM, analyst41@hotmail.com wrote:
....

> subroutine test
> if (0< huge(0)) print *, ' zero less than huge(0)'
> do j = 0,huge(0)
> if (j> 10) stop
> print *, j
> enddo
> stop
> end
>
>
> zero less than huge(0)
> Program Completed
> Press Enter to Continue.
>
> In other words, If I try to run the loop from 0 to huge(0) it never
> enters the loop.

C:\Temp> df /nologo test.f90
test.f90
test.f90(4) : Warning: Overflow occurred while evaluating constant
expression.
do i=0,huge(0)
--^

C:\Temp>

CVF 6.6c diagnoses a problem. I'll have to scratch head as to why,
precisely; it doesn't come to me otomh why the case w/ the lower
bound==1 is ok but 0 isn't (but I'm sure it'll be obvious when it does )

--

On 4/15/2012 9:31 AM, analyst41@hotmail.com wrote:
....

> In other words, If I try to run the loop from 0 to huge(0) it never
> enters the loop.

Yes, it occurred to me just as a pressed "SEND"

The compiler is computing the loop count and that count overflows by
being HUGE+1, not HUGE

--

On 4/15/2012 9:54 AM, dpb wrote:
> On 4/15/2012 9:31 AM, analyst41@hotmail.com wrote:
> ....
>
>> In other words, If I try to run the loop from 0 to huge(0) it never
>> enters the loop.
>
> Yes, it occurred to me just as a pressed "SEND"
>
> The compiler is computing the loop count and that count overflows by
> being HUGE+1, not HUGE

BTW,

program test
integer*8 :: i
do i=1,huge(0)
write(*,*) i
if (i>3) stop
enddo
end

C:\Temp> df /nologo test.f90
test.f90

C:\Temp> test
1
2
3
4

C:\Temp>

hth...

--

On 4/15/2012 9:59 AM, dpb wrote:
....

> BTW,
>
> program test
> integer*8 :: i
> do i=1,huge(0)
....

Which also works (of course) w/ the intended demonstration case of

program test
integer*8 :: i
do i=0,huge(0)

--

On Apr 15, 10:31*am, "analys...@hotmail.com" <analys...@hotmail.com>
wrote:
> * * * subroutine test
> * * * do j = 1,huge(0)
> * * * if (j > 10) stop
> * * * print *, j
> * * * enddo
> * * * stop
> * * * end
>
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> Program Completed
> Press Enter to Continue.
>
> * * * subroutine test
> * * * if (0< huge(0)) print *, ' zero less than huge(0)'
> * * * do j = 0,huge(0)
> * * * if (j > 10) stop
> * * * print *, j
> * * * enddo
> * * * stop
> * * * end
>
> *zero less than huge(0)
> Program Completed
> Press Enter to Continue.
>
> In other words, If I try to run the loop from 0 to huge(0) it never
> enters the loop.

Thanks all. 0,huge(0) - 1 did the trick.

In article <jmeo0h$l09$4@speranza.aioe.org>, dpb <none@non.net>
wrote:

> On 4/15/2012 9:59 AM, dpb wrote:
> ...
>
> > BTW,
> >
> > program test
> > integer*8 :: i
> > do i=1,huge(0)
> ...
>
> Which also works (of course) w/ the intended demonstration case of
>
> program test
> integer*8 :: i
> do i=0,huge(0)

I don't know how the latest languages standards have addressed this
issue, but with f90 and f95 it was not necessary for this version to
work either. The reason is that the trip count was often computed
or stored with default precision, regardless of the KINDs of the
loop index, lower bound, upper bound, or increment. I remember
testing several compilers in the late 1990's and early 2000's with
variations of

integer(i8) :: i, i1, i2
i1 = -huge(0_i4) ! or = 0
i2 = huge(0_i4)
do i = i1, i2


and they did not work correctly. Even with the trip count evaluated
entirely with 64-bit arithmetic, the counter itself was still stored
in a 32-bit register, which defeated the purpose of the exercise.
sometimes it was not the trip count that was the problem it was the
result of the trip count being optimized away in favor of one of the
address ranges of an array, so the limit was related to the
underlying address limitations of the hardware.

Some of the compilers had options to change the default integer
kind, and this did fix the problem in some cases but not others.
This was during the time when addressing was done with 32 bits, or
when extended addressing was first available in hardware but the OS
did not yet fully support it (e.g. MacOSX in 2003). Since it was
not required to work by the standard, the compiler vendors could
claim conformance and that this was a quality of implementation
issue.

I do not know if or how the later standard revisions addressed this
issue, but I do know that both hardware and OS support for extended
addressing is more common now, and it would surprise me if there
were not some kind of workaround to achieve the above on most of the
currently supported compilers. It might require using nondefault
KINDS for the trip count computation, or it might require changing
the default kind with a compiler option, but there almost certainly
is some way to get the above to work now.

It would sort of surprise me if simply changing the KIND of the loop
index alone is sufficient, but I could see how some compilers might
use that as a guideline. It is really the stuff on the *other* side
of the equals sign (lower and upper bound and the increment) that
would seem to be the most important in this process. The loop index
itself is often just optimized away (e.g. if it is not used in a
complicated expression or as an actual argument or something).

$.02 -Ron Shepard

On 4/15/2012 11:17 AM, Ron Shepard wrote:
....

> It would sort of surprise me if simply changing the KIND of the loop
> index alone is sufficient, but I could see how some compilers might
> use that as a guideline. It is really the stuff on the *other* side
> of the equals sign (lower and upper bound and the increment) that
> would seem to be the most important in this process. The loop index
> itself is often just optimized away (e.g. if it is not used in a
> complicated expression or as an actual argument or something).

Yeah, on retrospect I shouldn't have said "of course" in the comment on
how CVF handles it as there's no reason necessarily the count
computation needed to have been in the extended precision. But, it
appears that was what the developers did in that case (use the KIND of
the index variable as a hint, that is).

--

On 4/15/2012 10:18 AM, analyst41@hotmail.com wrote:
....

> Thanks all. 0,huge(0) - 1 did the trick.

You don't mean you actually _use_ that construct, do you!!!???

Surely there's a "more better" way (for what I presume is essentially
intended as a DO FOREVER construct until a condition of some sort breaks
it)?

--

On Apr 15, 2:06*pm, dpb <n...@non.net> wrote:
> On 4/15/2012 10:18 AM, analys...@hotmail.com wrote:
> ...
>
> > Thanks all. 0,huge(0) - 1 did the trick.
>
> You don't mean you actually _use_ that construct, do you!!!???
>
> Surely there's a "more better" way (for what I presume is essentially
> intended as a DO FOREVER construct until a condition of some sort breaks
> it)?
>
> --

cleanest way to count records from an external file. When you get out
the loop variable equals the number you read.

Try this change to narrow the problem down.
I have Lahey, but haven't used it for years, so I don't know what to expect
from 'huge(0)'.
A pure guess, but I suspect the original code would work if 'huge (0)' was
replaced by 99.

subroutine test
if (0< huge(0)) then
print *, ' zero less than huge(0)'
else
do j = 0,huge(0)
if (j > 10) stop
print *, j
enddo
endif
stop
end

Oops! More replies came in while I was researching it.
So I see the problem is the storing of 'huge(0)' and adding 1 to it and
getting either an overflow or a negative number result.

analyst41@hotmail.com <analyst41@hotmail.com> wrote:

> On Apr 15, 2:06 pm, dpb <n...@non.net> wrote:
> > On 4/15/2012 10:18 AM, analys...@hotmail.com wrote:
> > ...
> >
> > > Thanks all. 0,huge(0) - 1 did the trick.
> >
> > You don't mean you actually _use_ that construct, do you!!!???
> >
> > Surely there's a "more better" way (for what I presume is essentially
> > intended as a DO FOREVER construct until a condition of some sort breaks
> > it)?

> cleanest way to count records from an external file. When you get out
> the loop variable equals the number you read.

Well, to each his own on the definition of "cleanest". To me, having an
arbitrary loop upper bound like huge(0) seems far less clean than what I
do, which is to use an actual "do forever" loop, having a record count
separate from any loop index, as in

i = 0
read_loop: do
read(...,iostat=iostat) ...
if (iostat /= 0) exit read_loop
... do any desired processing of the record data here.
end do read_loop

That doesn't introduce arbitrary loop bounds like huge(0). To me that
huge(0) is pretty "unclean" in that it's actual value presumably doesn't
matter. After all, if you ever actually hit that upper bound, something
has gone wrong. That's before getting into the fact that it is prone to
overflow problems such as the one you hit.

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