Fortran - xlf passing mechanism test? Was: Re: MPI/Fortran95 incompatibility?

Author

xlf passing mechanism test? Was: Re: MPI/Fortran95 incompatibility?

Paul Van Delst

2006-01-10, 9:58 pm

Richard E Maine wrote:
> Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:
>
>
>
>
> Not necessarily. There is no reason to do so when the actual argument is
> contiguous. Just because the actual argument is a section, that doesn't
> mean it is discontiguous. Some compilers (I thought almost all current
> ones by now) check for this distinction rather than doing the same thing
> for all sections.
>
> As an aside, I find the terminology "subset" confusing to the extent
> that I'm not 100% sure what you mean by it. I assume that you mostly
> mean "section", which is what the standard uses (or "slice", which is a
> commonly used synonym), but I'm not sure if you are making some finer
> distinction. It isn't quite a subset of an array because an array is
> more than just a set of elements. (Maybe "subscript", which is parallel
> to "triplet" in being part of the notation?) A subscript triplet is just
> part of the syntax used to denote a section - it isn't the resulting
> object, or even the whole of the syntax.

Thanks for pointing that out. Yes I meant section, but I was sloppy.
>
>
>
>
> I guess that my question in turn was whether the assumed-shape part of
> the question was made explicit to them. For example, it was omitted in
> your decription to us, where you said
>
>
>
>
> I know from context that you were talking about assumed shape, but
> context can so easily get lost here. Since this doesn't explicitly refer
> to assumed shape, and appears to be making some distinction that I don't
> understand between a "subset" and a "triplet", it still leaves me
> wondering *EXACTLY* what question the IBM person was answering, and
> whether he was answering the same question that you intended to ask.
>
> Please note that I'm not actually meaning to critise your wording here
> (though I'm aware it might look like it - I hopy you don't mistake my
> intent). I'm just trying to determine whether there might have been a
> confusion about exactly what the question was. Heck, even if your
> wording was perfect, it could have been misheard, as the terms "assumed
> shape" and "assumed size" are awfully easy to confuse, and it turns out
> that the question makes sense (but often has different answers) for both
> cases. In fact, I'd say that the question is more often "at issue" for
> assumed size, so it would bee very easy for a person attuned to that
> issue to hear the question he expected rather than the one actually
> asked, even if you did word it precisely.

Fear not - precise wording takes me a couple of drafts. At least. :o)

At any rate, I took Jugoslav's advice and ran the following on the IBM here:

program testassumption
integer, parameter :: N = 10, J = 5, K = 2
real :: x(N), y(N,N)
integer :: i
x = (/( i, i = 1, N )/)
y = RESHAPE((/( i, i = 1, N*N )/),(/N,N/))
write(*,'(/,"Testing rank-1 array x")')
write(*,'(/,2x,"In main, LOC(x): ", i25)') LOC(x)
write(*,'(/,2x,"Section")')
call assumedshape( x(1:J) )
call assumedsize( x(1:J) )
write(*,'(/,2x,"Subscript triplet")')
call assumedshape( x(1:J:K) )
call assumedsize( x(1:J:K) )
write(*,'(/,2x,"Random array indexed")')
call assumedshape( x((/1,20,99,34,45,87,62,77/)) )
call assumedsize( x((/1,20,99,34,45,87,62,77/)) )
write(*,'(//,"Testing rank-2 array y in-order")')
do i = 1, N, K
write(*,'(/,2x,"In main, LOC(y(:,",i2,"): ", i25)') i, LOC(y(:,i))
call assumedshape( y(:,i) )
call assumedsize( y(:,i) )
end do
write(*,'(//,"Testing rank-2 array y out-of-order")')
do i = 1, N, K
write(*,'(/,2x,"In main, LOC(y(",i2,",:): ", i25)') i, LOC(y(i,:))
call assumedshape( y(i,:) )
call assumedsize( y(i,:) )
end do
contains
subroutine assumedshape( a )
real :: a(:)
write(*,'(2x,"In assumedshape, LOC(a): ", i25)') LOC(a)
end subroutine assumedshape
subroutine assumedsize( a )
real :: a(*)
write(*,'(2x,"In assumedsize, LOC(a): ", i25)') LOC(a)
end subroutine assumedsize
end program testassumption

The results I get are:

b2n15:/scratch : xlf95 -qsuffix=f=f90 testassumption.f90
** testassumption === End of Compilation 1 ===
1501-510 Compilation successful for file testassumption.f90.
b2n15:/scratch : a.out

Testing rank-1 array x

In main, LOC(x): 1152921504606842720

Section
In assumedshape, LOC(a): 1152921504606842720
In assumedsize, LOC(a): 1152921504606842720

Subscript triplet
In assumedshape, LOC(a): 1152921504606842720
In assumedsize, LOC(a): 1152921504606842688

Random array indexed
In assumedshape, LOC(a): 1152921504606842792
In assumedsize, LOC(a): 1152921504606842856

Testing rank-2 array y in-order

In main, LOC(y(:, 1): 1152921504606842928
In assumedshape, LOC(a): 1152921504606842928
In assumedsize, LOC(a): 1152921504606842928

In main, LOC(y(:, 3): 1152921504606843008
In assumedshape, LOC(a): 1152921504606843008
In assumedsize, LOC(a): 1152921504606843008

In main, LOC(y(:, 5): 1152921504606843088
In assumedshape, LOC(a): 1152921504606843088
In assumedsize, LOC(a): 1152921504606843088

In main, LOC(y(:, 7): 1152921504606843168
In assumedshape, LOC(a): 1152921504606843168
In assumedsize, LOC(a): 1152921504606843168

In main, LOC(y(:, 9): 1152921504606843248
In assumedshape, LOC(a): 1152921504606843248
In assumedsize, LOC(a): 1152921504606843248

Testing rank-2 array y out-of-order

In main, LOC(y( 1,:): 1152921504606842928
In assumedshape, LOC(a): 1152921504606842928
In assumedsize, LOC(a): 1152921504606842888

In main, LOC(y( 3,:): 1152921504606842936
In assumedshape, LOC(a): 1152921504606842936
In assumedsize, LOC(a): 1152921504606842888

In main, LOC(y( 5,:): 1152921504606842944
In assumedshape, LOC(a): 1152921504606842944
In assumedsize, LOC(a): 1152921504606842888

In main, LOC(y( 7,:): 1152921504606842952
In assumedshape, LOC(a): 1152921504606842952
In assumedsize, LOC(a): 1152921504606842888

In main, LOC(y( 9,:): 1152921504606842960
In assumedshape, LOC(a): 1152921504606842960
In assumedsize, LOC(a): 1152921504606842888

So, first a question: Is the test program a reasonable test? (I've never used LOC() before
so I don't know if I'm interpreting it correctly).

If so, then it would appear what I've been told about xlf is incorrect (or, as has been
pointed out <*SOB!*> twice now, my question might not have been fully understood).

For the assumed shape dummy, it would appear that when the actual argument is reasonably
"defined", i.e. with an array section, triplet, or slice, the dummy arg is *not* copied
when it is assumed shape. When the dummy is assumed size, copies may occur -- in this case
for the triplet and "out-of-order" array slices. For the psuedo-random array indexed case,
copies were produced in both cases.

The behaviour in all cases seems quite reasonable and is what I would have originally
expected (except for the assumed size *not* copying in some cases. That's a pleasant
surprise.)

cheers,

paulv

p.s. Any suggestions for making the above test more meaningful are welcome - I'd like to
send this to the IBM guy I've been talking to about this here.

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Richard E Maine

2006-01-10, 9:58 pm

Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:

> So, first a question: Is the test program a reasonable test?

Looks plausible to me at first glance (and the results are as I'd
expect).

I did figure out from it one of the terminology distinctions you are
making. Note that the form x(1:j) is an array section specified using a
subscript triplet, even though you explicity see only two numbers of the
triplet. In fact, even x(:) uses a triplet. If you see a colon in an
array reference, it is either part of a subscript triplet or a character
substring range, depending on context. The actual bnf for
subscript-triplet is

[ subscript ] : [subscript ] [ : stride ]

where the square brackets indicate optionality. Thus you can see that
the only mandatory part of the syntax is the first colon. All the other
parts have defaults; if you don't write them out, it is just as if you
had written them out with the default values. It isn't a different
syntax form - just a special case of the same one.

--
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

Jan Vorbrüggen

2006-01-11, 3:57 am

> p.s. Any suggestions for making the above test more meaningful are
> welcome - I'd like to send this to the IBM guy I've been talking to
> about this here.

Print the addresses with a Z8.8 instead of an I25 format.

I do think the results are very reasonable. Here's the output with the above
modification compiled with CVF 6.6C:

Testing rank-1 array x

In main, LOC(x): 0043A404

Section
In assumedshape, LOC(a): 0043A404
In assumedsize, LOC(a): 0043A404

Subscript triplet
In assumedshape, LOC(a): 0043A404
In assumedsize, LOC(a): 0012FEC4

Random array indexed
In assumedshape, LOC(a): 0012FEF0
In assumedsize, LOC(a): 0012FF30

Testing rank-2 array y in-order

In main, LOC(y(:, 1): 0043A42C
In assumedshape, LOC(a): 0043A42C
In assumedsize, LOC(a): 0043A42C

In main, LOC(y(:, 3): 0043A42C
In assumedshape, LOC(a): 0043A47C
In assumedsize, LOC(a): 0043A47C

In main, LOC(y(:, 5): 0043A42C
In assumedshape, LOC(a): 0043A4CC
In assumedsize, LOC(a): 0043A4CC

In main, LOC(y(:, 7): 0043A42C
In assumedshape, LOC(a): 0043A51C
In assumedsize, LOC(a): 0043A51C

In main, LOC(y(:, 9): 0043A42C
In assumedshape, LOC(a): 0043A56C
In assumedsize, LOC(a): 0043A56C

Testing rank-2 array y out-of-order

In main, LOC(y( 1,:): 0043A42C
In assumedshape, LOC(a): 0043A42C
In assumedsize, LOC(a): 0012FE30

In main, LOC(y( 3,:): 0043A42C
In assumedshape, LOC(a): 0043A434
In assumedsize, LOC(a): 0012FE30

In main, LOC(y( 5,:): 0043A42C
In assumedshape, LOC(a): 0043A43C
In assumedsize, LOC(a): 0012FE30

In main, LOC(y( 7,:): 0043A42C
In assumedshape, LOC(a): 0043A444
In assumedsize, LOC(a): 0012FE30

In main, LOC(y( 9,:): 0043A42C
In assumedshape, LOC(a): 0043A44C
In assumedsize, LOC(a): 0012FE30

As you can see, the optimizations are the same, but LOC contains a bug:
it always returns the base address of the array, instead of the actual
starting location in the case of the array sections! The dummy argument
in assumedshape, however, sees the correct starting address.

In the vector-subscript case, I suspect the actual data copy is identical,
but for the assumedshape case, the dope vector is generated in front of the
data.

Jan

glen herrmannsfeldt

2006-01-11, 7:56 am

Jan Vorbrüggen wrote:
(snip)

> In main, LOC(y( 7,:): 0043A42C
> In assumedshape, LOC(a): 0043A444
> In assumedsize, LOC(a): 0012FE30

> In main, LOC(y( 9,:): 0043A42C
> In assumedshape, LOC(a): 0043A44C
> In assumedsize, LOC(a): 0012FE30

> As you can see, the optimizations are the same, but LOC contains a bug:
> it always returns the base address of the array, instead of the actual
> starting location in the case of the array sections! The dummy argument
> in assumedshape, however, sees the correct starting address.

For a non-contiguous array the starting address is what is needed,
along with the information to calculate where each element is.

Some systems that I know of pass the address of the element with all
subscripts zero, even if that isn't part of the array. That, and
multipliers for each subscript are what the called routine needs
to find an array element.

> In the vector-subscript case, I suspect the actual data copy is identical,
> but for the assumedshape case, the dope vector is generated in front of the
> data.

-- glen

Jan Vorbrüggen

2006-01-11, 7:56 am

>> In main, LOC(y( 7,:): 0043A42C
[...][color=darkred]
> For a non-contiguous array the starting address is what is needed,
> along with the information to calculate where each element is.
>
> Some systems that I know of pass the address of the element with all
> subscripts zero, even if that isn't part of the array. That, and
> multipliers for each subscript are what the called routine needs
> to find an array element.

Indeed. But the evidence is in the other direction: In the _calling_ routine,
the address printed by LOC (y (7, :)) is the starting address of the array,
while in the _called_ routine, the address is that of the first element of
the slice being passed. That's why LOC has a bug!

Jan

glen herrmannsfeldt

2006-01-12, 3:58 am

Jan Vorbrüggen wrote:

(snip)

> Indeed. But the evidence is in the other direction: In the _calling_
> routine,
> the address printed by LOC (y (7, :)) is the starting address of the array,
> while in the _called_ routine, the address is that of the first element of
> the slice being passed. That's why LOC has a bug!

Old computer joke: What's the difference between a bug and a feature?

A: A feature is documented.

-- glen

Ron Shepard

2006-01-12, 3:58 am

In article < NZidnazKXfHGRFjenZ2dnUVZ_tGdnZ2d@comcast
.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Jan Vorbrüggen wrote:
>
> (snip)
>
>
> Old computer joke: What's the difference between a bug and a feature?
>
> A: A feature is documented.

Actually, this applies to this case. The IBM xlf documentation says:

"If it [the argument of LOC()] is an array section, the storage of
the array section must be contiguous."

and a little later

"The result is undefined if the argument is not valid."

The first sentence above says that the argument y(7,:) is not valid,
and the second says that as a consequence the result of LOC() is
undefined. In all of these cases, I think you could change the
argument to a scalar (e.g. LOC(y(7,1))) to get the desired results.

$.02 -Ron Shepard

glen herrmannsfeldt

2006-01-12, 3:58 am

Ron Shepard wrote:

(snip regarding XLF and LOC())

> The first sentence above says that the argument y(7,:) is not valid,
> and the second says that as a consequence the result of LOC() is
> undefined. In all of these cases, I think you could change the
> argument to a scalar (e.g. LOC(y(7,1))) to get the desired results.

The traditional way to call Fortran from PL/I is to put the first
element in the argument list. PL/I passes arrays by descriptor, but
array elements by reference. CHARACTER variables are always passed
by reference, though. I once modified the CALCOMP library routine
SYMBOL (or is it SYMBL1) to accept PL/I character variables.

-- glen

Jan Vorbrüggen

2006-01-12, 3:58 am

> Actually, this applies to this case. The IBM xlf documentation says:

However, the compiler in question - the one with the LOC() bug - is CVF.
And, by Glen's argument and your quote from the docs, XLF has a bug (as
it does work contrary to documentation) in that it doesn't reject the case
of discontiguous slices.

So there!

Jan

PS: Don't forget to add a pinch of salt...

Dave Seaman

2006-01-12, 7:58 am

On Thu, 12 Jan 2006 08:57:04 +0100, Jan Vorbrüggen wrote:
[color=darkred]
> However, the compiler in question - the one with the LOC() bug - is CVF.
> And, by Glen's argument and your quote from the docs, XLF has a bug (as
> it does work contrary to documentation) in that it doesn't reject the case
> of discontiguous slices.

> So there!

> Jan

The documentation doesn't say such a case will be rejected by the
compiler. Quite the contrary, the quoted documentation says that the
result is undefined.

> PS: Don't forget to add a pinch of salt...

At least it didn't start World War III.

Yet.

--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>

Sponsored Links