[Bug fortran/40045] New: ICE with type extension and -fdump-parse-tree

[Bug fortran/40045] New: ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

Segfault with -fdump-parse-tree:

type t
end type
type, extends(t) :: t2
end type t2
end


-- 
           Summary: ICE with type extension and -fdump-parse-tree
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janus at gcc dot gnu dot org


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2009-05-06 14:31 -------
Confirmed and this is regression with repect to 4.4.0:

[karma] f90/bug% gfc -fdump-parse-tree pr40045.f90

        Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
        procedure name = MAIN__
        symtree: MAIN__  Ambig 0
        symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

        symtree: t  Ambig 0
        symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
        Procedure bindings:

f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
          PROCEDURE, [karma] f90/bug% 
[karma] f90/bug% gfc44 -fdump-parse-tree pr40045.f90

        Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
        procedure name = MAIN__
        symtree: MAIN__  Ambig 0
        symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

        symtree: t  Ambig 0
        symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
        Procedure bindings:


        symtree: t2  Ambig 0
        symbol t2 (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC UNKNOWN)
        components: (t (DERIVED t) ())
        Procedure bindings:


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-05-06 14:39 -------
Regarding the segfault, valgrind shows:

==14376== Invalid read of size 1
==14376==    by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==    by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)

The line is:
            fprintf (dumpfile, "PASS(%s)", st->n.tb->pass_arg);
and the interesting question is: Why is it called? There are no type-bound
procedures (and also no components [except of t2%t]. Thus why is
  if (!st->n.tb)
    return;
not working?

 * * *

Related problem: The following gives: show_code_node(): Bad statement code

type t
  procedure(), nopass, pointer :: p
end type t
type(t) m
!external bar
!m%p => bar
call m%p()
end


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

------- Comment #3 from janus at gcc dot gnu dot org  2009-05-06 14:58 -------
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t]. 

If it's a regression it may be caused by Daniel's r146733 ("reworking
type-bound procedures")?!?



> Related problem: The following gives: show_code_node(): Bad statement code

I will handle this in my PPC patch before committing.


-- 

janus at gcc dot gnu dot org changed:

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


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

------- Comment #4 from domob at gcc dot gnu dot org  2009-05-06 15:01 -------
Yes, that sounds like a problem caused by my patch; it did change the structure
of storing the type-bounds, so maybe simply changing the if to the one shown by
Tobias was wrong.

I will look into this!


-- 

domob at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-06 15:01:04
               date|                            |


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

------- Comment #5 from domob at gcc dot gnu dot org  2009-05-14 20:03 -------
Subject: Bug 40045

Author: domob
Date: Thu May 14 20:02:46 2009
New Revision: 147540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147540
Log:
2009-05-14  Daniel Kraft  <d@domob.eu>

        PR fortran/40045
        * dump-parse-tree.c (show_typebound): Fix missing adaption to new
        type-bound procedure storage structure.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/dump-parse-tree.c


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

------- Comment #6 from domob at gcc dot gnu dot org  2009-05-14 20:05 -------
Fixed (not addressing the "related" part in comment #2, but Janus promised to
work on it).


-- 

domob at gcc dot gnu dot org changed:

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


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