[Bug fortran/41781] New: [OOP] bogus undefined label error with SELECT TYPE.

[Bug fortran/41781] New: [OOP] bogus undefined label error with SELECT TYPE.

[sfilippone at uniroma2 dot it]

With trunk at revision 153049 I get the following 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu45
--enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure
--prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20091021 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic'
 /usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 gotobug.f03
-quiet -dumpbase gotobug.f03 -mtune=generic -auxbase gotobug -version
-fintrinsic-modules-path
/usr/local/gnu45/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o
/tmp/ccidWMNg.s
GNU Fortran (GCC) version 4.5.0 20091021 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.5.0 20091021 (experimental), GMP version
4.2.4, MPFR version 2.4.1
warning: MPFR header version 2.4.1 differs from library version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.5.0 20091021 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.5.0 20091021 (experimental), GMP version
4.2.4, MPFR version 2.4.1
warning: MPFR header version 2.4.1 differs from library version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
gotobug.f03:17.15:

      goto 9999
               1
Error: Label 9999 referenced at (1) is never defined


on the attached code, which is obiviously a bogus claim. 
If I change the source code as follows:
---------------------
select type()
  ......
class default
  info = -1
end select
if (info /= 0) goto 9999
----------------------
then it works, so it's definitely an interaction with SELECT TYPE.


-- 
           Summary: [OOP] bogus undefined label error with SELECT TYPE.
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sfilippone at uniroma2 dot it
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[sfilippone at uniroma2 dot it]

------- Comment #1 from sfilippone at uniroma2 dot it  2009-10-21 09:34 -------
Created an attachment (id=18853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18853&action=view)
test case


-- 


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-10-21 09:38 -------
Similar / same problem:

   block
     goto 99
   end block
99 continue
   end


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|x86_64-unknown-linux-gnu    |
   GCC host triplet|x86_64-unknown-linux-gnu    |
 GCC target triplet|x86_64-unknown-linux-gnu    |
           Keywords|                            |rejects-valid


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[janus at gcc dot gnu dot org]

------- Comment #3 from janus at gcc dot gnu dot org  2009-10-21 13:17 -------
Created an attachment (id=18858)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18858&action=view)
patch

Mine. Preliminary patch attached.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-10-21 14:07 -------
While for
  goto 99
  if(.true.) then
  99 continue
  end if
  end
one gets (for if, do, select case) the nice warning (!) message:
  Warning: Label at (1) is not in the same block as the GOTO statement at (2)

One gets for
  goto 99
  block
    99 continue
  end block
  end
only:
  Error: Label 99 referenced at (1) is never defined

I think something nicer than "never defined" would be useful. One has also to
think about which of those should give a warning (like now) and which should
give a hard error.


I believe jumping *into* a (DO/IF/SELECT (TYPE/CASE)/BLOCK/ ...) block is
invalid, but they are all in the same scoping unit. However, I failed to find
this restriction.

The standard has:

R851 goto-stmt is GO TO label
C846 (R851) The label shall be the statement label of a branch target
            statement that appears in the same scoping unit as the goto-stmt.

1.3.115 scoping unit
either
- a program unit or subprogram, excluding any scoping units in it,
- a derived-type de\fnition (4.5.2), or
- an interface body, excluding any scoping units in it

Further restrictions (and some more related to branching to an END <x> only
from inside of the <x>):

C734 (R744) A statement that is part of a where-body-construct shall not be a
branch target statement.

C743 (R756) A forall-body-construct shall not be a branch target.

It is permissible to branch to an end-associate-stmt only from within its
ASSOCIATE construct.

C811 A statement that branches from the block of a critical-construct to
outside the critical-construct is not permitted. A CYCLE or EXIT statement in a
critical-construct that transfers control outside the critical-construct is not
permitted.

It is permitted to branch to the end-do of a block DO construct only from
within the range of that DO construct.

C824 A branch (8.2) within a DO CONCURRENT construct shall not have a branch
target that is outside the construct.


-- 


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[sfilippone at uniroma2 dot it]

------- Comment #5 from sfilippone at uniroma2 dot it  2009-10-21 14:23 -------

> 
> I believe jumping *into* a (DO/IF/SELECT (TYPE/CASE)/BLOCK/ ...) block is
> invalid, but they are all in the same scoping unit. However, I failed to find
> this restriction.
> 
That is what is spelled out clearly in the two translation from standardese
into English that I have, Metcalf Reid and Cohen page 54: "a goto statement
must never specify a branch into a block" and Fortran 2003 handbook page 280ff
"the statements that may be branch targets are those classified as action
statements plus the initial statements for ASSOCIATE, CASE, DO, FORALL, IF,
SELECT TYPE and WHERE, however it is not permitted to branch to a statement
within a block from outside the block. " plus some other things about the END
[something] often being a legitimate target. 
Thus I think both your examples should be rejected 


-- 


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2009-10-21 14:25 -------
Found it:

"8.1.2.1 Control 
flow in blocks
 Transfer of control to the interior of a block from outside the block is
 prohibited, except for the return from a procedure invoked within the block.
 Transfers within a block and transfers from the interior of a block to outside
 the block may occur."

> One has also to think about which of those should give a warning (like now)
> and which should give a hard error.

NAG f95 always rejects it.
ifort/gfortran/g95 allow it for IF, SELECT TYPE, DO, ASSOCIATE (only supported
by ifort).
ifort/gfortran reject it for SELECT TYPE (though gfortran only indirectly). I
think it should definitely remain like this!

Other blocks are BLOCK and CRITICAL.

Personally, I would not mind to reject it for SELECT TYPE, BLOCK, CRITICAL,
ASSOCIATE on the basis that this is a legacy feature.


-- 


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[janus at gcc dot gnu dot org]

------- Comment #7 from janus at gcc dot gnu dot org  2009-10-21 15:32 -------
Created an attachment (id=18860)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18860&action=view)
patch v2

With this updated patch the example in comment #4 is rejected with the correct
error message.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18858|0                           |1
        is obsolete|                            |


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[janus at gcc dot gnu dot org]

------- Comment #8 from janus at gcc dot gnu dot org  2009-10-22 08:53 -------
Subject: Bug 41781

Author: janus
Date: Thu Oct 22 08:53:26 2009
New Revision: 153446

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153446
Log:
2009-10-22  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41781
        * resolve.c (resolve_codes): Don't clear 'cs_base' for BLOCK
constructs,
        to make sure labels are treated correctly.
        * symbol.c (gfc_get_st_label): Create labels in the right namespace.
        For BLOCK constructs go into the parent namespace.


2009-10-22  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41781
        * gfortran.dg/goto_8.f90: New test case.

Added:
    trunk/gcc/testsuite/gfortran.dg/goto_8.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[janus at gcc dot gnu dot org]

------- Comment #9 from janus at gcc dot gnu dot org  2009-10-22 09:10 -------
With r153446, the codes in comment #1, #2 and #4 work as expected. I wanted to
get this out of the way quickly, so that we can make progress on Salvatore's
PSBLAS code, which still does not compile fully and continues to reveal bugs in
our OOP implementation.

Tobias, do you think there is anything left to do for this PR, or should we
close it? The codes in comment #4 are presently allowed as an extension (with a
warning), but rejected with -std=f2008.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.

[janus at gcc dot gnu dot org]

------- Comment #10 from janus at gcc dot gnu dot org  2009-12-11 16:09 -------
I think this one can be closed.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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