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;
2011-08-13 Mikael Morin <mikael.mo...@sfr.fr>
PR fortran/50071
* symbol.c (gfc_get_st_label): Use the derived type namespace when
we are parsing a derived type definition.
2011-08-13 Mikael Morin <mikael.mo...@sfr.fr>
PR fortran/50071
* gfortran.dg/duplicate_labels_2.f: New test.
diff --git a/symbol.c b/symbol.c
index b761cdd..4463460 100644
--- a/symbol.c
+++ b/symbol.c
@@ -2127,11 +2127,16 @@ gfc_get_st_label (int labelno)
gfc_st_label *lp;
gfc_namespace *ns;
- /* 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;
+ 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;
! { dg-do compile }
!
! PR fortran/50071
! Duplicate statement labels should not be rejected if they appear in
! different scoping units
!
! Contributed by Vittorio Zecca <zec...@gmail.com>
c gfortran complains about duplicate statement labels
c this is a legal program because types have their own scoping units
c and you may have same labels in different scoping units,
c as you may have same identifiers inside, like G.
type t1
1 integer G
end type
type t2
1 integer G
end type
c this is legal
goto 1
print *,'bad'
1 continue
print *,'good'
end
