[fortran] PR fortran/50071 Duplicate statement labels from different scoping units rejected.

Hello,

this patch fixes PR 50071 where statement labels in a type definition where 
hooked to the parent scoping unit instead of the type scoping unit.

From the standard:

- statement label (3.2.5):
The same statement label shall not be given to more than one statement in its 
scope.

- scoping unit (1.3.124)
BLOCK construct, _derived-type_ definition, interface body, program unit, 
or subprogram, excluding all nested scoping units in it.


Currently we ignore the derived type definition scoping unit, and thus reject 
the statement label if it is the same as another one outside the derived type 
definition. As it can't be used anyway, it makes sense to ignore it 
completely.

This patch puts the statement label in the derived_type->f2k_derived namespace 
if we are parsing a derived type definition.

Regression tested on x86_64-unknown-freebsd8.2. OK for trunk?
Even if it is a rejects-valid bug, I consider it as minor, and don't feel the 
need for backporting (but it can be discussed).

Mikael


*** a/symbol.c
--- b/symbol.c
*************** gfc_get_st_label (int labelno)
*** 2127,2137 ****
--- 2127,2144 ----
    gfc_st_label *lp;
    gfc_namespace *ns;
  
+   /* A derived type definition is a separate scoping unit, so that it has 
its
+      own set of statement labels.  */
+   if (gfc_current_state () == COMP_DERIVED)
+     ns = gfc_current_block ()->f2k_derived;
+   else
+     {
        /* Find the namespace of the scoping unit:
  	 If we're in a BLOCK construct, jump to the parent namespace.  */
        ns = gfc_current_ns;
        while (ns->proc_name && ns->proc_name->attr.flavor == FL_LABEL)
  	ns = ns->parent;
+     }
  
    /* First see if the label is already in this namespace.  */
    lp = ns->st_labels;

Hi Mikael,

Mikael Morin wrote:
> this patch fixes PR 50071 where statement labels in a type definition where
> hooked to the parent scoping unit instead of the type scoping unit.

I think the following is valid and it is still rejected (it is accepted 
by NAG 5.1 and ifort):

1 type t
     integer :: i
   end type t

   goto 1
1 print *, 'Hello'
end

Related but separate issue: BLOCK also starts a new scoping unit, but 
the following is rejected:

    block
      goto 1
      print *, 'Hello'
1    continue
    end block
1  continue
end


Also the following is rejected:

    block
      goto 1
      print *, 'Hello'
1  end block
end

variant, which is rejected (note: Associate does not start a new scoping 
unit, just a new block):

   integer :: i
   associate (j => i)
     goto 1
     print *, 'Hello'
1  end associate
end

Tobias