[patch,wip] warn on noncontiguous pointers

[Bader, Reinhold]

Hello all, 

> We had a lengthy discussion on that one. Still, we can dig into the
> standard for that one.
>
> J3/10-007 says in 7.2.2.3  Data pointer assignment
>
> # 7 If the pointer object has the CONTIGUOUS attribute, the pointer
> # target shall be contiguous.
>
> # 9 If bounds-remapping-list is specified, the pointer target shall
> # be simply contiguous (6.5.4) or of rank one
>
> program test
>   implicit none
>   real,pointer :: fptr1(:)
>   real,pointer,contiguous :: fptr3(:,:,:)
>
>   allocate(fptr1(12))
>   call random_number(fptr1)
>
>   !Test pointer reshape II
>
>   fptr3(1:2,1:2,1:2) => fptr1(4:)
>
> end program
>
> So, by paragraph 9, this would be OK. Let's see what paragraph 7
> means when it says "contiguous". 5.3.7 says
>
> An object is contiguous if it is
>
> # (1) an object with the CONTIGUOUS attribute,
> # (2) a nonpointer whole array that is not assumed-shape,
> # (3) an assumed-shape array that is argument associated with an
>     array that is contiguous,
> # (4) an array allocated by an ALLOCATE statement,
> # (5) a pointer associated with a contiguous target, or
> # (6) a nonzero-sized array section (6.5.3) provided that
> #   (a) its base object is contiguous,
> #   (b) it does not have a vector subscript,
> #   (c) the elements of the section, in array element order, are a
> #       subset of the base object elements that are consecutive in
> #       array element order,
> #   (d) if the array is of type character and a substring-range appears,
> #       the substring-range specifies all of the characters of the
> #       parent string (6.4.1),
> #   (e) only its final part-ref has nonzero rank, and
> #   (f) it is not the real or imaginary part (6.4.4) of an array of type
> #       complex.
>
> An object is not contiguous if it is an array subobject, and
>
> [conditions not relevant elided]
>
> # It is processor dependent whether any other object is contiguous.
>
> If we go down the list, we see that fptr1(4:) is not contiguous; it
> is not an array (it is a pointer), so (4) also does not apply.

I don't agree with this conclusion. First, the array and pointer properties
are not mutually exclusive (they are conveyed by specifying the DIMENSION
and
POINTER attribute, independently). 
Specifically for the array section fptr1(4:) all conditions 
in item (6) are fulfilled, and therefore it is a contiguous TARGET suitable
for appearing on the RHS of a contiguous pointer assignment.

Regards
Reinhold



>
> So, we are in the realm of processor dependent behavior, so we can
> chose what to do.
>
> The last time we discussed this, we agreed on a hard error.  One
> important argument is that a mistakenly applied contiguous
> attribute will lead to wrong code, and that it is quite easy
> to check this, as we do now.
> 
> So, I think we should leave the behavior as it is now, and
>
>> Maybe the ScaTeLib code needs to be updated.
>
> sounds like a good idea to me.
> 
> Regards
>
>       Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7773 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20180927/b1e8fdeb/attachment.p7s>