On Fri, Aug 02, 2024 at 04:58:09PM +0200, Mikael Morin wrote:
> > But the function actually returns 0 rather than 1 that PR45019 meant.
> > So I bet in addition to fixing the pasto we should move that conditional
> > from where it is right now to the return 0; location after
> > check_data_pointer_types calls.
> >
> No, the function check_data_pointer_types returns true if there is no
> aliasing, according to its function comment, so after both calls everything
> is safe and returning anything but 0 is overly pessimistic.
My (limited) understanding is that the original PR is about some corner case
in the standard wording where in order to allow aliasing of TARGET vars with
POINTER vars it also makes valid the weirdo stuff in the testcase.
And so should return 1 which means that they possibly alias.
> > And the pasto fix would guess fix
> > aliasing_dummy_5.f90 with
> > arg(2:3) = arr(1:2)
> > instead of
> > arr(2:3) = arg(1:2)
> > if the original testcase would actually fail.
> >
> Mmh, aren't they both actually the same?
It is just bad choice of variable/argument names, I also originally thought
they are the same, but they aren't.
arr is a variable in the parent routine which is passed to the arg dummy,
both have TARGET attribute and one of them is assumed shape and so that
"the dummy argument has the TARGET attribute, the dummy argument does not have
IN-
TENT (IN), the dummy argument is a scalar object or an assumed-shape array
without the
CONTIGUOUS attribute, and the actual argument is a target other than an array
section
with a vector subscript."
means that
"Action that affects the value of the entity or any subobject of it shall be
taken
only through the dummy argument"
is not true and so one can doesn't need to access the object just through
arg, but can access it as arr as well and those two can alias.
Jakub
