(j3.2006) Question about Comment GB20 on CFI_is_contiguous

Bill Long longb
Mon Oct 3 11:15:32 EDT 2011

On 9/29/11 7:16 PM, Malcolm Cohen wrote:
> -----Original Message-----
> From: Bill Long
> Date: ?????? 23???9???29??? 13:02
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) Question about Comment GB20 on CFI_is_contiguous
> <<<
>> the "otherwise" specifies the result as 0. Similarly, if the descriptor
>> is for a scalar, "otherwise" wins.  If the intent is to use this result
>> to employ some optimized code for the case of the result = 1, then these
>> result values give you what you need.
>> This is completely unacceptable, and *NOT* what the programmer needs at all.
> I don't understand.  This is exactly what I, as a programmer, would
> want.  What do you want that is different?

I see two general cases where using CFI_is_contiguous would be interesting.

1) The function expects a descriptor for an object of a particular rank. 
  In this case, a test for obj->rank != expected_rank would go to error 
return code; otherwise the user might check for contiguous if the 
expected_rank > 0.  If the expected_rank is 0, then it would be 
pointless to call CFI_is_contiguous.

2) The function expects a descriptor for an object of arbitrary rank. 
In this case, I would test for obj->rank==0 separately.  If obj->rank > 
0 then CFI_is_contiguous being true would branch to code that multiplies 
the extents together (effectively collapsing the loop nest) and executed 
a single loop for the whole array. And generates vector code (for 
systems that only vectorize for stride-1), and perhaps sends the whole 
execution to a GPU.  None of these optimizations would be appropriate 
for a scalar, which has no extents to multiply together, and would not 
benefit from vectorization.  If you do not have a contiguous object, 
then the less optimal code path gets executed.  So, three code paths total.

>> Should the programmer be asking about a scalar descriptor (because of
>> assumed-rank), then for the scalar case he DEFINITELY DOES NOT WANT to use the
>> "unoptimised" code seeing as how the object is not discontiguous.
> The concept of "contiguous" is meaningless for a scalar.  Why would you
>    want to go through the optimized code?   The optimization is likely
> meaningless for a scalar.
> Contrariwise, why do you want to go through the code that is set up to handle
> discontiguous chunks when there is a scalar?  All that extra work to handle

Certainly would not do that. See above.


> discontiguous chunks is not only meaningless for a scalar but a pessimisation!
> The reason for asking about contiguity is not to "enable optimisation", it is to
> enable *the normal way C works* (see penultimate paragraph below).
> <<<
> I'm OK with requiring that the C descriptor actually describe an object,
> As the existing text requires.
> <<<
> and making it a programmer error to supply a descriptor for an
> unallocated allocatable or disassociated pointer.
> Which matches the Fortran intrinsic, and arguably follows from the existing
> text, but is not clearly stated and thus interp fodder; it would be good to have
> a clear statement like we do for several of the other functions.
> <<<
>    I assume this comes
> under C's undefined behavior, and the program can do what it wants.
> Umm, that's "the *PROCESSOR* can do what it pleases"... but I'm sure that's what
> you meant.
> <<<
> Including returning 0, which is the useful choice anyway.
> Since ".NOT.IS_CONTIGUOUS" implies that we have an object "with gaps", and thus
> we need special processing to handle the gaps, we clearly have different ideas
> of what the "useful" return value should be.  The normal C situation is that
> every object is contiguous, so it is the *discontiguous* state that is unusual,
> and also requires more work.
> Since an array with one element is contiguous, it would be more than surprising
> to discover that both "is_contiguous(scalar)" is allowed and required to return
> FALSE!  I suppose having such a perverse definition might encourage programmers
> to check the rank first though... but if we are going that route, just don't
> allow "is_contiguous(scalar)".
> Cheers,

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list