This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, F08] PR45290: pointer initialization


Janus Weil wrote:
> Tobias Burnus wrote:
> > - ? ?integer(c_int), dimension(:), pointer :: int_ptr
> > - ? ?my_c_ptr = c_loc(int_ptr(0))
> >
> > Well, as written is is invalid - but change it to
> >
> > - ? ?integer(c_int), dimension(:), pointer :: int_ptr
> > ALLOCATE(int_ptr(0:10))
> > - ? ?my_c_ptr = c_loc(int_ptr(0))
> >
> > Then it is valid.
>
> ... which means that a through check for validity is
> very hard to do at compile time, since it depends on
> the run-time value, right?

Yes, like most pointer-initialization problems, most cannot
be detected at compile time and some only with quite some
effort. However, for compiling,
  my_c_ptr = c_loc(int_ptr(0))
it should be enough to decide whether (based on that line and
the function/variable declarations) it could be valid - and
if so, one accepts the code. In the example, one could track
whether "int_ptr" is ever pointer associated or allocated
before using it; I think NAG's f95 does some of these checks,
though I found a bug where v5.1 refuses to compile a perfectly
valid code because the check misses a valid method to make
the (in that case) allocatable allocated.


> Well, ok. I guess that is one way to look at it. However, if I apply
> the same logic to your earlier pointer-init example ...
>
> module m
>  integer, target, save  :: t1
>  integer, pointer :: p1 => t1
>  integer, pointer :: p3 => p1
> end module m
>
> ... then I'd say this is valid, too. p1 itself is a pointer, but the
> thing that it points to is a target (namely t1). Therefore "p3 => p1"
> is valid, since the object on the RHS has the TARGET attribute. Can we
> agree on that?

Over night I came to the same conclusion. But I think it is only valid if
the pointer on the RHS is pointer-associated (note: after "p => NULL()",
"p" is unassociated) - otherwise the status of the pointer is undefined
or unassociated and no TARGET exists.

But maybe one should ask for a second standard interpretation at j3 or
c.l.f to make sure we interprete it correctly. As this thread shows, it
is very easy to get on the wrong track.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]