public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/50121] New: Labels in a TYPE statement should be put in the derived type's scope
@ 2011-08-18 23:15 mikael at gcc dot gnu.org
2011-08-18 23:18 ` [Bug fortran/50121] " mikael at gcc dot gnu.org
2011-08-19 8:05 ` burnus at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-08-18 23:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50121
Bug #: 50121
Summary: Labels in a TYPE statement should be put in the
derived type's scope
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: mikael@gcc.gnu.org
Follow-up to PR 50071, reported by Tobias at:
http://gcc.gnu.org/ml/fortran/2011-08/msg00109.html
gfortran doesn't put labels declared in a derived type in their own scope.
PR 50071 fixed all cases but the one where the label is in the first line of
the derived type definition:
1 type t
integer :: i
end type t
goto 1
1 print *, 'Hello'
end
This case is more difficult, as at the time we insert the label, we haven't
parsed the TYPE statement yet, thus the derived type scope is not available
yet.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/50121] Labels in a TYPE statement should be put in the derived type's scope
2011-08-18 23:15 [Bug fortran/50121] New: Labels in a TYPE statement should be put in the derived type's scope mikael at gcc dot gnu.org
@ 2011-08-18 23:18 ` mikael at gcc dot gnu.org
2011-08-19 8:05 ` burnus at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-08-18 23:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50121
--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> 2011-08-18 23:16:31 UTC ---
The snippet above is rejected with:
pr50121.f90:1.1:
1 type t
1
pr50121.f90:6.1:
1 print *, 'Hello'
2
Error: Duplicate statement label 1 at (1) and (2)
pr50121.f90:1.1:
1 type t
1
pr50121.f90:5.9:
goto 1
2
Error: Statement at (1) is not a valid branch target statement for the branch
statement at (2)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/50121] Labels in a TYPE statement should be put in the derived type's scope
2011-08-18 23:15 [Bug fortran/50121] New: Labels in a TYPE statement should be put in the derived type's scope mikael at gcc dot gnu.org
2011-08-18 23:18 ` [Bug fortran/50121] " mikael at gcc dot gnu.org
@ 2011-08-19 8:05 ` burnus at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-08-19 8:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50121
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-08-19
CC| |burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-08-19 07:33:46 UTC ---
For completeness, the program in comment 0 works with g95, NAG, ifort,
openf95/pathf95.
(Though, in case of g95 seemingly by ignoring such labels in TYPE as adding
another to the same type is not diagnosed. The other compilers do diagnose
this.)
Variant - failing in the same way with gfortran but working with the compiler
mentioned above.
1 integer :: a
1 type t
integer :: i
end type t
end
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-08-19 7:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-18 23:15 [Bug fortran/50121] New: Labels in a TYPE statement should be put in the derived type's scope mikael at gcc dot gnu.org
2011-08-18 23:18 ` [Bug fortran/50121] " mikael at gcc dot gnu.org
2011-08-19 8:05 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).