Hi Thomas,
thanks for the comments.
> It feels a bit strange to have a check for an allocatable
> behind -fcheck=pointer, but I'm not sure that introducing
> a special check option would really be worth it.
Yes, I thought about that. There's already a discrepancy between
the GFC_RTCHECK_* in libgfortran.h, which has
#define GFC_RTCHECK_DO (1<<3)
#define GFC_RTCHECK_POINTER (1<<4)
#define GFC_RTCHECK_MEM (1<<5)
without the latter being documented, and gfortran.texi, which has
[...] GFC_RTCHECK_DO (16), GFC_RTCHECK_POINTER (32), [...]
-fcheck=mem should be checking memory allocations for things
other than allocate (according to invoke.texi), like temporaries.
-fcheck=pointer says:
Enable generation of run-time checks for pointers and allocatables.
So that is at least consistent.
(Note to self: submit patch for obvious documentation fixes).
> Regarding pointers: They are usually not nullified (unless
> they are global). What do people think about adding a
> NULL initializer to their data components when -fcheck=pointer is in
> force?
I was surprised when looking at the dump-tree difference of
integer, pointer :: a(:)
vs.
integer, pointer :: a(:) => NULL()
The latter has the expected:
static struct array01_integer(kind=4) a = {.data=0B};
while the former has:
struct array01_integer(kind=4) a;
a.span = 0;
Why setting .span at all, and not setting a.data = 0B ?
> Regarding size(x%re): You would have to chase the refs to find
> the allocatable components.
I was probably too tired and drifted off from the subject.
This is a more generic issue and not related to size().
> However, I think your patch already makes the situation better for
> the user, so I'd say it is good for trunk already; later improvements
> are always possible.
Yes. Will commit soon.
Thanks again,
Harald
