GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 41781 - [OOP] bogus undefined label error with SELECT TYPE.
Summary: [OOP] bogus undefined label error with SELECT TYPE.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-10-21 09:34 UTC by Salvatore Filippone
Modified: 2009-12-11 16:09 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test case (227 bytes, text/plain)
2009-10-21 09:34 UTC, Salvatore Filippone
Details
patch (597 bytes, patch)
2009-10-21 13:17 UTC, janus
Details | Diff
patch v2 (602 bytes, patch)
2009-10-21 15:32 UTC, janus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2009-10-21 09:34:12 UTC
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.
Comment 1 Salvatore Filippone 2009-10-21 09:34:46 UTC
Created attachment 18853 [details]
test case
Comment 2 Tobias Burnus 2009-10-21 09:38:48 UTC
Similar / same problem:

   block
     goto 99
   end block
99 continue
   end
Comment 3 janus 2009-10-21 13:17:51 UTC
Created attachment 18858 [details]
patch

Mine. Preliminary patch attached.
Comment 4 Tobias Burnus 2009-10-21 14:07:56 UTC
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 denition (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.
Comment 5 Salvatore Filippone 2009-10-21 14:23:49 UTC
> 
> 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 
Comment 6 Tobias Burnus 2009-10-21 14:25:08 UTC
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.
Comment 7 janus 2009-10-21 15:32:30 UTC
Created attachment 18860 [details]
patch v2

With this updated patch the example in comment #4 is rejected with the correct error message.
Comment 8 janus 2009-10-22 08:53:47 UTC
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

Comment 9 janus 2009-10-22 09:10:57 UTC
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.
Comment 10 janus 2009-12-11 16:09:07 UTC
I think this one can be closed.