[Patch, Fortran, F08] PR45290: pointer initialization

[Tobias Burnus]

Janus Weil wrote at http://gcc.gnu.org/ml/fortran/2010-08/msg00222.html:
> > Yes, like most pointer-initialization problems, most cannot
> > be detected at compile time and some only with quite some
> > effort. [...]
> Ok. I'm certainly not very keen on implementing this right now

Well, I was not suggesting it to you to implement it ;-)

> Anyway, would it be ok if I commit the bulk changes needed for
> pointer init now (i.e. version #2 of the patch as posted
> yesterday), and take care of the remaining problems afterwards?

I assume, you mean: pr45290_v2.diff of
http://gcc.gnu.org/ml/fortran/2010-08/msg00203.html

That patch is OK.

> The remaining problems being:
>
> (2) Making global variables in a program SAVE_IMPLICIT.
> If I do that (analogously to module variables), then I get a couple of
> regressions, e.g.: [...]
> It seems that SAVE_IMPLICIT messes up automatic deallocation ...

You could insert code in resolve_symbol of the kind
  /* Despite implicit SAVE, free and finallize allocatables of
     the main program.  */
  if (sym->attr.save == SAVE_IMPLICIT && sym->attr.allocatable
      && sym->ns->proc_name->attr.is_main_program)
    sym->attr.save = SAVE_NONE


> (1) Initializing to a pointer:
>
> module m
>  implicit none
>  integer, target, save  :: t1
>  integer, pointer :: p1 => t
>  integer, pointer :: p2 => p1    ! ICE
> end module m

When you fix this, please check (in the test case) that "p2"
is indeed associated with "t" and not with "p1".

Additionally, I think one should reject it if the RHS is not
initialized or if it is NULL initialized as in both cases there
cannot be any target on the RHS. (Check also the case LHS == RHS
[invalid] and RHS being an array with non-vector array designator.

Maybe start with the doing the right checks in decl.c - maybe the
ICE disappears then automatically.

Tobias