[Bug fortran/66056] New: Segmentation fault for lonely label in type

[Bug fortran/66056] New: Segmentation fault for lonely label in type

[gerhard.steinmetz.fortran@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

            Bug ID: 66056
           Summary: Segmentation fault for lonely label in type
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gerhard.steinmetz.fortran@t-online.de
  Target Milestone: ---

This code fragment with a lonely label in a type ...
   program p
      type t
      1 !
      end type
   end

or this variation ...
   program p
      type t
      ; 1 ;
      end type
   end

produces (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
internal compiler error: Segmentation fault

---

Similar, but with a lonely real number instead ...
   program p
      type t
      1.2 !
      end type
   end

or this variation ...
   program p
      type t
      ; 1.2 ;
      end type
   end

leads to ...
Warning: Ignoring statement label in empty statement at (1)
(null):0: confused by earlier errors, bailing out

Kind regards.

[Bug fortran/66056] Segmentation fault for lonely label in type

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This one is interesting.  If you compile with -O or -O2,
then there is no ICE.

[Bug fortran/66056] Segmentation fault for lonely label in type

[gerhard.steinmetz.fortran@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

--- Comment #3 from Gerhard Steinmetz <gerhard.steinmetz.fortran@t-online.de> ---
The following test file generates an endless compilation for every
subroutine. It's worth looking deeper.


$ cat type_with_lonely_numbers.f90
program p
   call s1
   call s2
   call s3
   call s4
   call s5
   call s6

contains

   subroutine s1
      type t
         integer :: n = 1
         1 !
         1 !
      end type
      type(t) :: a
      print *, a
   end

   subroutine s2
      type t
         integer :: n = 1
         ; 1 ;
         ; 1 ;
      end type
      type(t) :: a
      print *, a
   end

   subroutine s3
      type t
         integer :: n = 1
         1.2 !
         1.2 !
      end type
      type(t) :: a
      print *, a
   end

   subroutine s4
      type t
         integer :: n = 1
         ; 1.2 ;
         ; 1.2 ;
      end type
      type(t) :: a
      print *, a
   end

   subroutine s5
      type t
         integer :: n = 1
         1=2 !
         1=2 !
      end type
      type(t) :: a
      print *, a
   end

   subroutine s6
      type t
         integer :: n = 1
         1-2 !
         1-2 !
      end type
      type(t) :: a
      print *, a
   end
end

[Bug fortran/66056] Segmentation fault for lonely label in type

[gerhard.steinmetz.fortran@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

--- Comment #4 from Gerhard Steinmetz <gerhard.steinmetz.fortran@t-online.de> ---
These two do not circle around,


$ cat y1.f90
program p
   type t
      integer :: n = 1
      1 !
      2 !
   end type
   type(t) :: a
   print *, a
end


$ cat y2.f90
program p
   type t
      integer :: n = 1
      ; 1 ;
      ; 2 ;
   end type
   type(t) :: a
   print *, a
end


but answer :
f951: internal compiler error: insert_bbt(): Duplicate key found!

[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type

[lkrupp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

--- Comment #6 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Mon Oct 26 19:18:08 2015
New Revision: 229390

URL: https://gcc.gnu.org/viewcvs?rev=229390&root=gcc&view=rev
Log:
2015-10-26  Louis Krupp  <louis.krupp@zoho.com>

        PR fortran/66056
        * fortran.h: Include namespace pointer in statement label
        structure.
        * symbol.c (gfc_get_st_label): Store pointer to namespace
        that owns the statement label tree in each label.
        (gfc_free_st_label): Use namespace owning statement label
        tree when deleting statement label.
        * io.c: Initialize format_asterisk with NULL namespace pointer.

2015-10-26  Louis Krupp  <louis.krupp@zoho.com>

        PR fortran/66056
        * gfortran.dg/empty_label_typedecl.f90: New test

Added:
    trunk/gcc/testsuite/gfortran.dg/empty_label_typedecl.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/io.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type

[lkrupp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056

lkrupp at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |lkrupp at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #7 from lkrupp at gcc dot gnu.org ---
Fixed in revision 229390.

The problem: Statement labels within a type declaration are put in the
statement label tree belonging to the type declaration's namespace's (instead
of the current namespace). When the line is otherwise empty and an error is
issued, gfc_free_st_label tries to delete the label from the label tree
belonging to the current namespace and then frees the label structure, leaving
an invalid statement label pointer in the type declaration's namespace's label
tree. When that namespace is cleaned up, bad things can happen.

The attached patch stores a namespace pointer in the statement label structure
so that if a label is deleted early for some reason, it will be deleted from
the proper namespace.