Why is Lahey Fortran is erroring here?

Hi all,

any ideas to help me out here? It concerns
Lahey/Fujitsu Fortran 95 Compiler Release L6.20c (patched to c from a) and
a *very* simple call to one of the *simplest* BLAS subroutines.
Lahey changes the values of an array that is *not* even passed
to the subroutine! Same results produced before the patch too.

 ========================================
=======

INTEGER :: ia = 10,  incx=2, incy1=2, incy2=3, i
INTEGER, PARAMETER :: n=10
INTEGER, DIMENSION(n) :: ix =(/(i, i=1,n)/), iy

iy = ix                  ! IX has correct values here
CALL iscal(n,ia,iy,incx)
! but not here!!!!
 ========================================
=======

Both intel fortran 8.0 and g95 (october release)
produce correct results.

All run on a SuSE 9.1 (default kernel)

/Sakis

Athanasios Migdalas wrote:

>
> Hi all,
>
> a *very* simple call to one of the *simplest* BLAS subroutines.

Yes, yes, it is not in the standrad BLAS, its a rewritten sscal/dscal  for
all parameters of integer type.

/Sakis

"Athanasios Migdalas" <migdalas@ergasya.tuc.gr> wrote in message
news:1101177623.344425@athnrd02...

> INTEGER :: ia = 10,  incx=2, incy1=2, incy2=3, i
> INTEGER, PARAMETER :: n=10
> INTEGER, DIMENSION(n) :: ix =(/(i, i=1,n)/), iy
>
> iy = ix                  ! IX has correct values here
> CALL iscal(n,ia,iy,incx)
>                          ! but not here!!!!

Touching iy(20) is an error.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Athanasios Migdalas wrote:
> Hi all,
>
> any ideas to help me out here? It concerns
> Lahey/Fujitsu Fortran 95 Compiler Release L6.20c (patched to c from a) and
> a *very* simple call to one of the *simplest* BLAS subroutines.
> Lahey changes the values of an array that is *not* even passed
> to the subroutine! Same results produced before the patch too.
>
>  ========================================
=======
>
> INTEGER :: ia = 10,  incx=2, incy1=2, incy2=3, i
> INTEGER, PARAMETER :: n=10
> INTEGER, DIMENSION(n) :: ix =(/(i, i=1,n)/), iy
>
> iy = ix                  ! IX has correct values here
> CALL iscal(n,ia,iy,incx)
>                          ! but not here!!!!
>  ========================================
=======

Assuming it is like SSCAL, with incx=2 you should have
array IY dimensioned at least 19.  You are writing past
the end of your array, into the next one in memory.

-- glen

In article <1101177623.344425@athnrd02>,
Athanasios Migdalas <migdalas@ergasya.tuc.gr> wrote:

> CALL iscal(n,ia,iy,incx)

I think this call is equivalent to:

call iscal(10, 10, iy(1:10), 2)

If so, then iy(:) is probably being addressed outside of its
declared range within iscal().  Of course, you don't show what
iscal() does, but I'm guessing that it uses BLAS-1 conventions for
its arguments.

$.02 -Ron Shepard

glen herrmannsfeldt wrote:

>
> Athanasios Migdalas wrote: 
>
> Assuming it is like SSCAL, with incx=2 you should have
> array IY dimensioned at least 19.  You are writing past
> the end of your array, into the next one in memory.

But Glen, if the problem was the one you mention, in an open interface,
say thrhough USE myBlas or similar, shouldn't this error be trapped at
compilation, linking or run time? Should checkbnds be necessarily on?
>
> -- glen


Thank you all for your answers, *However*, strangely enough after a reboot
of the machine, Lahey behaves exactly similar to the other two compilers
mentioned above !? I *cannot* reproduce the error any more!


/Sakis

Athanasios Migdalas <migdalas@ergasya.tuc.gr> writes:

> But Glen, if the problem was the one you mention, in an open interface,
> say thrhough USE myBlas or similar, shouldn't this error be trapped at
> compilation, linking or run time? Should checkbnds be necessarily on?

1. This sounds awfully hypothetical when you say "say through USE myBlas
or similar".  It would be most pertinent to ask whether the error should
be detected in what you actually *DID* do instead of whether it should
be trapped in some other hypothetical situation.  But...

2. In any case, even in the hypothetical situation that you had an
explicit interface (I assume that's what you mean by "open
interface"), no array size limits are not necessarily caught at
compilation time.  Array sizes are not necessarily known at compilation
or link time, so all cases certainly cannot be caught.  Some compilers
might catch some cases, but this is not required by the standard and I
would not necessarily expect all compilers to do so.

As for run time, that's exactly what array bounds checking is about.
I'm not entirely sure what you meanby asking "should checkbounds be
necessarily on" because it seems like a tautology, but to answer what
the question appears to be... yes, you have to have runtime bounds
checking (whatever the compiler's name for that option is) on in
order to get runtime bounds checking.  :-)  I suppose the question
is more likely whether you can count on this being caught before runtime.
The fact that such errors cannot always be caught before runtime is
why runtime bounds checking options exist.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Richard E Maine" <nospam@see.signature> wrote in message
news:m1fz30xy30.fsf@MLMCE0000L22801.local...

> As for run time, that's exactly what array bounds checking is about.
> I'm not entirely sure what you meanby asking "should checkbounds be
> necessarily on" because it seems like a tautology, but to answer what
> the question appears to be... yes, you have to have runtime bounds
> checking (whatever the compiler's name for that option is) on in
> order to get runtime bounds checking.  :-)  I suppose the question
> is more likely whether you can count on this being caught before runtime.
> The fact that such errors cannot always be caught before runtime is
> why runtime bounds checking options exist.

But only one of his compilers is capable of checking bounds in the
O.P.'s context.  If we look at the preamble for sscal from

http://gams.nist.gov/serve.cgi/Modu...polyhedron.com/

and then clicking on Fortran -> Linux Compiler Comparisons ->
Diagnostic Capabilities, it appears that this error is BND5
which LF95 (and your fave, NAG) can nail, but Intel can't.
I dunno about g95.  My original impression was that the O.P.
had all the error-checking stuff enabled so that only LF95
was going to detect this error, but evidently he did not, and
it was just through luck (that Intel or g95 could equally have
experienced) that the memory written to ended up adversely
affecting program functionality.  A reboot could have changed
the memory layout.  One reason why some compilers enable
totally paranoid bounds checking: normally these bugs don't
show up in testing, just when the program is in production,
or when you're trying to impress someone with your programming
brilliance...

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:

>
> "Richard E Maine" <nospam@see.signature> wrote in message
> news:m1fz30xy30.fsf@MLMCE0000L22801.local...
> 
>
> But only one of his compilers is capable of checking bounds in the
> O.P.'s context.  If we look at the preamble for sscal from
>
>
http://gams.nist.gov/serve.cgi/Modu.../NETLIB/sscal.f
>
>       subroutine sscal(n,sa,sx,incx)
> c
> c     scales a vector by a constant.
> c     uses unrolled loops for increment equal to 1.
> c     jack dongarra, linpack, 3/11/78.
> c     modified 3/93 to return if incx .le. 0.
> c     modified 12/3/93, array(1) declarations changed to array(*)
> c
>       real sa,sx(*)
>       integer i,incx,m,mp1,n,nincx
>
> We see that dummy argument sx is assumed size.  Going to
>
Exactly, now think of * replaced by :, and also think that sscal is a BLAS
module, and that you USE that BLAS module. This is the context which this
happens (is not hypothetica), just sscal is replaced by an iscal and the
corresponding reals by integers.

> http://www.polyhedron.com/
>
> and then clicking on Fortran -> Linux Compiler Comparisons ->
> Diagnostic Capabilities, it appears that this error is BND5
> which LF95 (and your fave, NAG) can nail, but Intel can't.
> I dunno about g95.  My original impression was that the O.P.
> had all the error-checking stuff enabled so that only LF95
> was going to detect this error, but evidently he did not, and
> it was just through luck (that Intel or g95 could equally have
> experienced) that the memory written to ended up adversely
> affecting program functionality.  A reboot could have changed
> the memory layout.  One reason why some compilers enable
> totally paranoid bounds checking: normally these bugs don't
> show up in testing, just when the program is in production,
> or when you're trying to impress someone with your programming
> brilliance...
>

Very good point, especially if you mistakenly think, as I was totally
conviced, that the days
of going pass the array bounds and not being cought at least at run time,
had been left behind (and to the C pointers). However, I now read, in
Lahey's User Guide, something I would have done earlier, I admit it, that
bound checking must be enabled by hand, since by default the compiler does
not enable this option.

Thank you all guys,

/Sakis