[Bug fortran/50550] New: does not recognize pointer variable at initialization (r178939)

[Bug fortran/50550] New: does not recognize pointer variable at initialization (r178939)

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

             Bug #: 50550
           Summary: does not recognize pointer variable at initialization
                    (r178939)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: zeccav@gmail.com


! does not recognize pointer variable at initialization (r178939) 
      pointer pi,pr,pl,pc,pcmplx
      integer   :: pi=>null()
      real      :: pr=>null()
      logical   :: pl=>null()
      character :: pc=>null()
      complex   :: pcmplx=>null()
      end

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2011-09-28 20:00:54 UTC ---
The cases in comment #0 are rather easily fixable in the current
implementation. However, the harder case will be the following:

integer :: j => null()
pointer :: j
end

because when parsing the init, we don't know yet whether the object is a
pointer or not (which means the check would have to be deferred to resolution
stage).

Looking at F08:R505 and friends, I don't see an obvious reason why any of the
cases listed here should be forbidden.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-22
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Still present at revision 200321.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a simple patch to accept the code in comment 0:


Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c    (revision 200258)
+++ gcc/fortran/decl.c    (working copy)
@@ -1197,6 +1197,9 @@ build_sym (const char *name, gfc_charlen *cl, bool

   sym->attr.implied_index = 0;

+  /* Update current_attr with merged symbol attributes.  */
+  current_attr = sym->attr;
+
   if (sym->ts.type == BT_CLASS)
     return gfc_build_class_symbol (&sym->ts, &sym->attr, &sym->as, false);



For cases like the one in comment 1, more work is required (which probably
involves moving the corresponding check to resolution stage). Provided it is
valid at all.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Here is a simple patch to accept the code in comment 0:


... which unfortunately introduces a large amount of ICEs in the testsuite,
e.g. on bounds_check_7.f90:

bounds_check_7.f90:5:0: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1265
 subroutine foo(a)
 ^
0x5d3a03 gfc_get_symbol_decl(gfc_symbol*)
        /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:1265
0x5d441f generate_local_decl
        /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4726
0x5a2d43 do_traverse_symtree
        /home/janus/gcc49/trunk/gcc/fortran/symbol.c:3571
0x5d65ba generate_local_vars
        /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4885
0x5d65ba gfc_generate_function_code(gfc_namespace*)
        /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:5460


That line is

      /* Dummy variables should already have been created.  */
      gcc_assert (sym->backend_decl);

however, I don't directly see how the failure comes about.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[markeggleston at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

markeggleston at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markeggleston at gcc dot gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
@@ -2858,7 +2858,8 @@ variable_decl (int elem)
     {
       if (gfc_match (" =>") == MATCH_YES)
        {
-         if (!current_attr.pointer)
+         gfc_find_symbol (name, gfc_current_ns, 1, &sym);
+         if (!(current_attr.pointer || (sym && sym->attr.pointer)))
            {
              gfc_error ("Initialization at %C isn't for a pointer variable");
              m = MATCH_ERROR;

The contents of current_attr only applies to the line currently being parsed so
will not have the pointer attribute.  In the case where the pointer attribute
has already been declared a matching symbol should exist that has that
attribute set.

However, if the pointer attribute is declared after the initialisation it is
not known when initialisation line is parsed.  The parsing of pointer occurs
after the initialisation parsing is complete.

For this to be fixed where the attribute is declared after initialisation error
detection would have to be deferred until after parsing has been completed.

The above change does not result in any unexpected test case failures when
running make with check-fortran.

I'm no longer working on this PR as I do not know how to proceed.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

--- Comment #9 from Vittorio Zecca <zeccav at gmail dot com> ---
Intel ifort and ifx accept the test case without errors.

They both accept

pointer pi
integer :: pi=>null()

and

integer :: pi=>null()
pointer pi

Anyway, it's easy to transfom it into

integer, pointer :: pi=>null()

which is accepted by gfortran.

Evidently ifx and ifort have a different approach to symbol table and
compilation passes.