Question on scoping of LOC argument
Paul Curtis
n_sent = 0
DO WHILE (n_sent < ncout)
lret = WriteFile (port_handle, &
LOC(outbuf(n_sent+1:)), &
ncout - n_sent, &
LOC(n_thistime), &
os)
n_sent = n_sent + n_thistime
END DO
This works fine with CVF compilers thru 6.6A, brings 6.6B to its knees with a C0000005 complexity error. The problem is with the use of a scoped argument to the LOC() function.
Question: what functionality should be expected for constructs such as LOC(array(not_the_beginning:))?
Is this improper, or should a compiler be expected to resolve this correctly?
TIA, Paul Curtis
Richard Maine
> LOC(outbuf(n_sent+1:)), &
...
> This works fine with CVF compilers thru 6.6A, brings 6.6B to its
> knees with a C0000005 complexity error. The problem is with the use
> of a scoped argument to the LOC() function.
> Question: what functionality should be expected for constructs such
> as LOC(array(not_the_beginning:))?
>
> Is this improper, or should a compiler be expected to resolve this correctly?
Well, LOC isn't standard, so it is hard to say what is "proper". But I
can make a few comments about what seems intuitively sensible to me.
1. Seems to me that the concept of LOC of an array slice (any array
slice) has possible subtleties. In general, an array slice might not
be contiguous and might be passed by copy-in/copy-out to some
subroutines. I could just imagine something happening here like LOC
trying to take the address of a temporary copy of the slice. I don't
know that this is what really happened; you wouldn't think that LOC
"ought" to work like that...but I could imagine problems like that if
someone forgot to think about it in putting LOC into the compiler.
LOC probably requires special handling in the compiler, and it
wouldn't be shocking if the special handling forgot some unusual case.
2. Seems to me that there isn't much point in writing something like
LOC of an array slice anyway. The only "sensible" interpretation of
LOC(outbuf(nsent+1:)) is that it equals LOC(outbuf(nsent+1)), so why
not write the simpler form? Perhaps whoever implemented LOC was
thinking similarly and forgot to allow for the more complicated form.
3. In all the above, I assume that the slice outbuf(nsent+1:) has
nonzero size. It is legal for a slice like that to have zero size,
but you might have *SERIOUS* difficulty in getting meaningful and
consistent answers for LOC of a zero-sized slice. (Particularly
if you wanted the answers to be consistent with what I regard as
the rather strange special-case rules about associations of zero-sized
objects)
P.S. I had to wrap the lines of your posting so that I could read them.
--
Richard Maine | Good judgment comes from experience;
email: my last name at host.domain | experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov | -- Mark Twain
James Van Buskirk
"Paul Curtis" <pcu...@kiltel.com> wrote in message
news:3E384A44...@kiltel.com...
> n_sent = 0
> DO WHILE (n_sent < ncout)
> lret = WriteFile (port_handle, &
> LOC(outbuf(n_sent+1:)), &
> ncout - n_sent, &
> LOC(n_thistime), &
> os)
> n_sent = n_sent + n_thistime
> END DO
> This works fine with CVF compilers thru 6.6A, brings 6.6B to its knees
with a C0000005 complexity error. The problem is with the use of a scoped
argument to the LOC() function.
I think C0000005 is an access violation during compilation, perhaps
caused by complexity but it means something different. Have you
tried just passing outbuf(nsent+1:) instead of LOC(outbuf(nsent+1:))
and if that is rejected, just inserting:
!DEC$ ATTRIBUTES NO_ARG_CHECK :: lpBuffer
in the interface block for KERNEL32.F90 in
C:\Program Files\Microsoft Visual Studio\DF98\INCLUDE (or whereever
it may reside in your computer) and recompiling to get a new
KERNEL32.MOD? Seems to make no sense to have a LOC in there
when CVF would pass an address by default in any case.
Steve Lionel
wrote:
This is a compiler bug. An "Internal compiler error" (which is what
the message says - the word "complexity" is not used) is always a
compiler bug. I see that you already sent this to vf-support -
thanks.
Your usage of LOC is a bit unusual. I would expect that the argument
would be outbuf(nsent+1), not an array slice. I guess we didn't
consider the possibility that one might put an array-valued expression
in there.
We'll fix the compiler to either accept this or give a proper error
message. I'd suggest removing the colon.
Please send Visual Fortran support requests to vf-su...@compaq.com
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Fortran and Compaq Visual Fortran:
http://intel.com/IDS/community