On 09/26/2018 01:49 PM, Thomas Koenig wrote: > Hi Cesar, > >> As of GCC 8, gfortran now errors when a pointer with a contiguous >> attribute is set to point to a target without a contiguous attribute. I >> think this is overly strict, and should probably be demoted to a >> pedantic warning as I've done in the attached patch. > > 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. > > 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
Thank you for the explanation. That all seems reasonable. >> Maybe the ScaTeLib code needs to be updated. > > sounds like a good idea to me. ACK. Thanks, Cesar
