[patch, fortran] Warn about suspicious assignment to contiguous pointers

Thomas Koenig tkoenig@netcologne.de
Tue Aug 29 18:13:00 GMT 2017


Hi Janus,

>>>> I think an unconditional warning is OK
>>>> in this case because
>>>>
>>>> - Assigning to a pointer from an obvious non-contiguous target
>>>>     is not useful at all, that I can see
>>>
>>>
>>> I guess you're talking about a *contiguous* pointer here,
>>
>> Correct.
>>
>>> and in that
>>> case I would argue that, beyond being "not useful", it's even illegal,
>>> so why not throw a hard error, if we can infer at compile-time that
>>> the target is non-contiguous?
>>
>> Problem is, we cannot infer this from the tests done.
>> We would also have to add a test if the array is empty
>> or that it contains only a single element, and that (I think)
>> is a) impossible in the general case, and b) not worth the bother.
> 
> I'm not sure I understand which cases you're worried about here. Maybe
> you can give an example?


   real, dimension(5,5), target :: a
   real, dimension(:,:), pointer, contiguous :: ap
   ap => a(4::2,4::2)

points to a single element, which is (by definition) contiguous.

> In any case, I think your test case is a bit short, so I extended it
> somewhat (see attachment) and found two cases along the way where your
> patch throws a warning but shouldn't:
> 
> r => x(::-1)

This one is _not_ contiguous; contiguos implies stride==1.

> r => x2(2:3,1)

Correct, I will correct that one.

> Apart from the two mishandled cases above, one other thing comes to my
> mind: It might be a good idea to apply your checks not only to pointer
> assignments, but also to dummy arguments (passing a non-contiguous
> array to a contiguous dummy pointer), where the same rules should
> apply.

This is true.

There are also a few other checks that I missed, for
example

   subroutine foo(a)
   real, dimension(:), target, intent(inout) :: a
   real, dimension(:), contiguous :: ap
   ap => a

I will also address this in a future version of the patch. This will
take a bit of time, though.

Regards

	Thomas



More information about the Fortran mailing list