[Bug fortran/42274] New: ICE: segmentation fault

[Bug fortran/42274] New: ICE: segmentation fault

[sfilippone at uniroma2 dot it]

The attached code gives an ICE against the fortran-dev branch as of r154975.
[sfilippo@donald bug12]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../fortran-dev/configure --prefix=/usr/local/gnudev
--enable-languages=c,c++,fortran : (reconfigured) ../fortran-dev/configure
--prefix=/usr/local/gnudev --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20091203 (experimental) (GCC) 

[sfilippo@donald bug12]$ gfortran  -c bug12.f03 
bug12.f03:229:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE: segmentation fault
           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=42274

[Bug fortran/42274] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

------- Comment #1 from sfilippone at uniroma2 dot it  2009-12-04 14:30 -------
Created an attachment (id=19223)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19223&action=view)
test case


-- 


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

[Bug fortran/42274] ICE: segmentation fault

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-12-04 14:48 -------
Fortran people - if you want to use bugzilla for fortran-dev please add a
fortran-dev version people can report bugs against.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.5.0                       |unknown


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

[Bug fortran/42274] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2009-12-04 14:58 -------
The code compiles with [trunk revision 154654]. It looks like a regression.


-- 


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

[Bug fortran/42274] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

------- Comment #4 from sfilippone at uniroma2 dot it  2009-12-04 15:02 -------
(In reply to comment #3)
> The code compiles with [trunk revision 154654]. It looks like a regression.
> 
Yes, I know, this is due to the recent work by Paul Thomas and Janus Weil about
the dynamic dispatching implementation via vtables. I opened a PR to have a
clear track for this problem. 
Richard is probably right, it should be clearly marked against the branch,
except that I have neither the knowledge nor the authorization for doing it. 

Salvatore 


-- 

sfilippone at uniroma2 dot it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.5.0


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-12-04 15:57 -------
> (In reply to comment #3)
> Richard is probably right, it should be clearly marked against the branch,

I have now set "Reported against" to 'fortran-dev', marked it in the Subject
line and in 'known to work/fail'

Backtrace:

mio_pointer_ref (gp=0x28) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2237
2237          p = get_pointer (*((char **) gp));
(gdb) bt
#0  mio_pointer_ref (gp=0x28) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2237
#1  0x00000000004f8da9 in mio_symbol_ref (symp=<value optimized out>) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2498
#2  0x00000000004f90e9 in mio_typebound_proc (proc=0x154b908) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:3352
#3  0x00000000004fa344 in mio_component (c=0x154b880) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2362


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |fortran-dev
      Known to work|                            |4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-04 15:57:20
               date|                            |
            Summary|ICE: segmentation fault     |[fortran-dev Regression]
                   |                            |ICE: segmentation fault
            Version|unknown                     |fortran-dev


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #6 from janus at gcc dot gnu dot org  2009-12-04 17:06 -------
(In reply to comment #5)
> #3  0x00000000004fa344 in mio_component (c=0x154b880) at
> /home/tob/projects/fortran-dev/gcc/fortran/module.c:2362

The component here is 'is_null', and the parent symbol is
'vtype$psb_d_base_sparse_mat'. In this context, the component 'is_null' refers
to the PPC of the vtype, not the TBP of the original type.

I think the problem is that c->tb->ppc is not set correctly for the PPCs inside
vtype. If one looks at psb_base_mat_mod.mod, one finds:

(55 'is_null'
(LOGICAL 4 0 0 LOGICAL ()) () (PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC
DECL UNKNOWN 0 0 EXTERNAL FUNCTION PROCEDURE PROC_POINTER) PRIVATE (
NULL (UNKNOWN 0 0 0 UNKNOWN ()) 0) 56 (57) (PUBLIC OVERRIDABLE PASS
SPECIFIC NO_PPC 'a' 0 30))

Note the 'NO_PPC'! Although this clearly *is* a PPC, as indicated by
'PROC_POINTER', the tb.ppc attribute is missing.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #7 from janus at gcc dot gnu dot org  2009-12-04 19:43 -------
(In reply to comment #6)
> I think the problem is that c->tb->ppc is not set correctly for the PPCs inside
> vtype.

The following patches fixes it:

Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c        (revision 154956)
+++ gcc/fortran/symbol.c        (working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   if (!c->tb)
     c->tb = XCNEW (gfc_typebound_proc);
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->attr.procedure = 1;
   c->attr.proc_pointer = 1;
   c->attr.flavor = FL_PROCEDURE;
@@ -4790,6 +4791,7 @@ add_proc_comps (gfc_component *c, gfc_symbol *vtyp
   else if (c->attr.proc_pointer && c->tb)
     {
       *c->tb = *st->n.tb;
+      c->tb->ppc = 1;
       c->ts.interface = st->n.tb->u.specific->n.sym;     
     }
 }
@@ -4886,7 +4888,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy
       c->attr.flavor = FL_PROCEDURE;
       c->attr.access = ACCESS_PRIVATE;
       c->attr.external = 1;
-      c->ts.interface = cmp->tb->u.specific->n.sym;
+      c->ts.interface = cmp->ts.interface;
       c->attr.untyped = 1;
       c->attr.if_source = IFSRC_IFBODY;
       c->initializer = gfc_get_expr ();


-- 

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|NEW                         |ASSIGNED
   Last reconfirmed|2009-12-04 15:57:20         |2009-12-04 19:43:51
               date|                            |


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2009-12-04 21:37 -------
With the patch in comment #7 the tests in pr41829 and the following ones
segfault at runtime.

!--------------------------------

module m
  type :: t1
    integer :: i = 42
  contains
    procedure, pass :: prod => i_m_j
  end type t1
  type, extends(t1) :: t2
    integer :: j = 99
  end type t2
contains
  integer function i_m_j (arg)
    class(t1), intent(in) :: arg
    select type (arg)
      type is (t1)
        i_m_j = 0
      class is (t2)
        i_m_j = 1
      class default
        print *, "should not be here"
    end select
  end function i_m_j
end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  type(t2), target :: c
  integer :: itmp
  a => b
  itmp = a%prod()
  print *, itmp
  a => c
  itmp = a%prod()
  print *, itmp
end

!--------------------------------

module m

  type :: null_type
  end type

  type :: t1
    integer :: i = 42
    procedure(make_real), pointer :: ptr
  contains
    procedure, pass :: real => make_real
    procedure, pass :: make_integer
    procedure, pass :: prod => i_m_j
    generic, public :: extract => real, make_integer
  end type t1

  type, extends(t1) :: t2
    integer :: j = 99
  contains
    procedure, pass :: real => make_real2
    procedure, pass :: make_integer_2
    procedure, pass :: prod => i_m_j_2
    generic, public :: extract => real, make_integer_2
  end type t2

contains

  real function make_real (arg)
    class(t1), intent(in) :: arg
    make_real = real (arg%i)
  end function make_real

  real function make_real2 (arg)
    class(t2), intent(in) :: arg
    make_real2 = real (arg%j)
  end function make_real2

  integer function make_integer (arg, arg2)
    class(t1), intent(in) :: arg
    integer :: arg2
    make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
    class(t2), intent(in) :: arg
    integer :: arg2
    make_integer_2 = arg%j * arg2
  end function make_integer_2

  integer function i_m_j (arg)
    class(t1), intent(in) :: arg
        i_m_j = arg%i
  end function i_m_j

  integer function i_m_j_2 (arg)
    class(t2), intent(in) :: arg
        i_m_j_2 = arg%j
  end function i_m_j_2

end module m


  use m
  class(t1), pointer :: a !=> NULL()
  type(t1), target :: b
  type(t2), target :: c
  a => b
  print *, a%i,a%real(), a%prod(), a%extract (2)
  a => c
  print *, a%i,a%real(), a%prod(), a%extract (3)
end


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #9 from janus at gcc dot gnu dot org  2009-12-05 11:20 -------
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Confirmed. This may be an initialization issue of the vtypes. Reduced test
case:

module m
  type :: t1
    integer :: i = 42
  contains
    procedure, pass :: prod => i_m_j
  end type t1
contains
  integer function i_m_j (arg)
    class(t1), intent(in) :: arg
    print *,"in i_m_j"
    i_m_j = 0
  end function i_m_j
end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  integer :: itmp
  a => b
  itmp = a%prod()
  print *, itmp
end


-- 

janus at gcc dot gnu dot org changed:

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


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2009-12-05 13:31 -------
With the patch in comment #7 the tests gfortran.dg/class_9.f03 and
gfortran.dg/dynamic_dispatch_[1-6].f03 also give a segfault at runtime.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #11 from janus at gcc dot gnu dot org  2009-12-05 15:14 -------
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Since these run fine with a clean fortran-dev, this is a regression of my
patch, more exactly of the following part:

Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c        (revision 154956)
+++ gcc/fortran/symbol.c        (working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   if (!c->tb)
     c->tb = XCNEW (gfc_typebound_proc);
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->attr.procedure = 1;
   c->attr.proc_pointer = 1;
   c->attr.flavor = FL_PROCEDURE;

However, I fail to see why. Paul, do you have an idea?


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2009-12-05 16:41 -------
Removing the line outlined in comment#11, slightly improve the situation:
class_9.f03 and dynamic_dispatch_5.f03, and the test in comment #9 now pass and
I get for pr41829.f90:

[macbook] f90/bug% gfc pr41829.f90 
[macbook] f90/bug% a.out 
 FOO%DOIT base version
 Getit value :            1
Segmentation fault


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

------- Comment #13 from pault at gcc dot gnu dot org  2009-12-06 13:32 -------
(In reply to comment #11)

> However, I fail to see why. Paul, do you have an idea?
> 

I have loaded fortran-dev and this PR onto my laptop - I'm on the road again
this week.

I'll see if I have anything to offer.  In the mean time, there are various
problems associated with vtables that I would like to deal with

Cheers

Paul


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #14 from janus at gcc dot gnu dot org  2009-12-10 21:21 -------
Comparing the dump of the test case in comment #9 with and without the patch in
comment #11 shows that with the patch the following is missing:

@@ -25,10 +25,6 @@ MAIN__ ()
   integer(kind=4) itmp;
   extern struct vtype$t1 vtab$t1;

-  if (vtab$t1.prod == 0B)
-    {
-      vtab$t1.prod = (integer(kind=4) (*<T41d>) (void)) i_m_j;
-    }
   a.$vptr = &vtab$t1;
   a.$data = &b;
   itmp = a.$vptr->prod (&a);


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #15 from dominiq at lps dot ens dot fr  2010-03-02 09:47 -------
I just opened pr43227 for a similar regression. For the record the backtrace
for the test in comment#1 with fortran-dev revision 157148 is

(gdb) run pr42274.f90
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/gcc/gcc4.5d/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
pr42274.f90
 is_null csclip d_csgetblk d_csgetrow d_b_csclip d_csclip is_null
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028
mio_pointer_ref (gp=0x28) at ../../for_work/gcc/fortran/module.c:2251
2251          p = get_pointer (*((char **) gp));
(gdb) bt
#0  mio_pointer_ref (gp=0x28) at ../../for_work/gcc/fortran/module.c:2251
#1  0x0000000100059c79 in mio_symbol_ref (symp=<value temporarily unavailable,
due to optimizations>) at ../../for_work/gcc/fortran/module.c:2512
#2  0x0000000100059fc9 in mio_typebound_proc (proc=0x1418e8040) at
../../for_work/gcc/fortran/module.c:3381
#3  0x000000010005b3ee in mio_component (c=0x1418e7fb0) at
../../for_work/gcc/fortran/module.c:2376
#4  0x000000010005b578 in mio_symbol (sym=0x1418e7690) at
../../for_work/gcc/fortran/module.c:2393
#5  0x000000010005b9ed in write_symbol (n=40, sym=0x1418e7690) at
../../for_work/gcc/fortran/module.c:4787
#6  0x000000010005ba9f in write_symbol1 (p=0x14187c560) at
../../for_work/gcc/fortran/module.c:4856
#7  0x000000010005ba65 in write_symbol1 (p=0x141870080) at
../../for_work/gcc/fortran/module.c:4860
#8  0x000000010005ba65 in write_symbol1 (p=0x14186ff60) at
../../for_work/gcc/fortran/module.c:4860
#9  0x000000010005ba53 in write_symbol1 (p=0x14187c8c0) at
../../for_work/gcc/fortran/module.c:4851
#10 0x000000010005ba65 in write_symbol1 (p=0x1418ce660) at
../../for_work/gcc/fortran/module.c:4860
#11 0x000000010005ba65 in write_symbol1 (p=0x1418cc130) at
../../for_work/gcc/fortran/module.c:4860
#12 0x000000010005ba65 in write_symbol1 (p=0x141868b70) at
../../for_work/gcc/fortran/module.c:4860
#13 0x000000010005ba65 in write_symbol1 (p=0x14187ab80) at
../../for_work/gcc/fortran/module.c:4860
#14 0x000000010005ba65 in write_symbol1 (p=0x14187b480) at
../../for_work/gcc/fortran/module.c:4860
#15 0x000000010005ba65 in write_symbol1 (p=0x1418c7e60) at
../../for_work/gcc/fortran/module.c:4860
#16 0x000000010005ba53 in write_symbol1 (p=0x1418c03c0) at
../../for_work/gcc/fortran/module.c:4851
#17 0x000000010005ba65 in write_symbol1 (p=0x1418c4e00) at
../../for_work/gcc/fortran/module.c:4860
#18 0x000000010005ba65 in write_symbol1 (p=0x1418c28e0) at
../../for_work/gcc/fortran/module.c:4860
#19 0x000000010005ba65 in write_symbol1 (p=0x141825cb0) at
../../for_work/gcc/fortran/module.c:4860
#20 0x000000010005ba65 in write_symbol1 (p=0x1418a87e0) at
../../for_work/gcc/fortran/module.c:4860
#21 0x000000010005d6dc in gfc_dump_module (name=0x7fff5fbfd3ad "",
dump_flag=<value temporarily unavailable, due to optimizations>) at
../../for_work/gcc/fortran/module.c:5006
#22 0x0000000100069b5b in gfc_parse_file () at
../../for_work/gcc/fortran/parse.c:4226
#23 0x00000001000a2f4c in gfc_be_parse_file (set_yydebug=<value temporarily
unavailable, due to optimizations>) at
../../for_work/gcc/fortran/f95-lang.c:239
#24 0x00000001006d61ea in toplev_main (argc=2, argv=0x7fff5fbfd968) at
../../for_work/gcc/toplev.c:1053
#25 0x00000001000017f4 in start ()


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #16 from janus at gcc dot gnu dot org  2010-04-22 20:58 -------
For completeness, here is a reduced/modified version of the original test case
in comment #1:


module mod_A
  type :: t1
  contains 
    procedure,nopass :: fun
  end type
contains
  logical function fun()
  end function
end module

module mod_B
  use mod_A
  type, extends(t1) :: t2
  contains
    procedure :: sub1
  end type
contains 
  subroutine sub1(a)
    class(t2) :: a
  end subroutine
end module

module mod_C
contains 
  subroutine sub2(b)
    use mod_B
    type(t2) :: b
  end subroutine
end module

module mod_D
  use mod_A
  use mod_C
end module


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #17 from janus at gcc dot gnu dot org  2010-04-25 14:32 -------
Created an attachment (id=20482)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482&action=view)
patch v2

The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs (hopefully). However, (at least) the following
regressions are left (all including generic TBPs):

* dynamic_dispatch_{1-3,5,7}.f03 in the testsuite
* comment #8 example 2


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #18 from janus at gcc dot gnu dot org  2010-04-25 14:42 -------
Here is a maximally reduced version of comment #8 example 2, which still fails
with the patch in comment #17:

module m
  type :: t1
  contains
    procedure :: make_integer
    generic :: extract => make_integer
  end type
contains
  integer function make_integer (arg)
    class(t1), intent(in) :: arg
    make_integer = 3
  end function
end module

  use m
  class(t1), allocatable :: a
  allocate(a)
  print *, a%extract ()
end


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #19 from janus at gcc dot gnu dot org  2010-04-25 14:56 -------
Created an attachment (id=20484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484&action=view)
patch v3

Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:

* dynamic_dispatch_{1-3}.f03


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

------- Comment #20 from pault at gcc dot gnu dot org  2010-04-25 16:27 -------
(In reply to comment #19)
Janus,

When I got up this morning, I made a start on documenting the fortran-dev
version of gfc_find_derived_vtab with a view to understand the code flow and to
understand why the original patch was failing.

My suspicion, which is strengthened by the remaining regressions for version 3
of your fix, is that the generic components of the vtab should not be marked as
ppc.  I have been tempted to apply it blind but have been trying to analyse
first :-)  That does not mean that you should not give it a shot, though!

Cheers

Paul


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #21 from dominiq at lps dot ens dot fr  2010-04-25 16:38 -------
> Here is an updated patch, which fixes (among others) comment #8 example 2 and
> comment #18. The remaining regressions are:
> 
> * dynamic_dispatch_{1-3}.f03

I also have

[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03: In function
'check_in_module':
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0: internal
compiler error: Segmentation fault
[macbook] f90/bug% gfc pr43199.f90
pr43199.f90: In function 'char_less_equal_string':
pr43199.f90:162:0: internal compiler error: Segmentation fault

Note that this may be due to some interference between the patch in comment #19
and other ones I have in my tree.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #22 from janus at gcc dot gnu dot org  2010-04-25 16:43 -------
(In reply to comment #21)
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0: internal
> compiler error: Segmentation fault

Yes, I can confirm that: typebound_operator_{3,4}.f03 both fail with an ICE.
Thanks for pointing that out. I haven't checked the full testsuite yet.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #23 from janus at gcc dot gnu dot org  2010-04-25 17:09 -------
Created an attachment (id=20485)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485&action=view)
patch v4

The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #24 from janus at gcc dot gnu dot org  2010-04-25 17:16 -------
(In reply to comment #20)
> My suspicion, which is strengthened by the remaining regressions for version 3
> of your fix, is that the generic components of the vtab should not be marked as
> ppc.  I have been tempted to apply it blind but have been trying to analyse
> first :-)  That does not mean that you should not give it a shot, though!

Well, in the light of today's progress I am quite optimistic that it should be
possible to have everything working with all the 'ppc' attributes in place.

Note that many cases of generic TBPs are working already. The remaining
failures seem to be related to generic TBPs with overriding.

The following is a reduced version of the runtime failure in
dynamic_dispatch_1.f03:


module m

  type :: t1
    integer :: i = 42
  contains
    procedure, pass :: make_integer
    generic, public :: extract => make_integer
  end type t1

  type, extends(t1) :: t2
    integer :: j = 99
  contains
    procedure, pass :: make_integer_2
    generic, public :: extract => make_integer_2
  end type t2

contains

  integer function make_integer (arg, arg2)
    class(t1), intent(in) :: arg
    integer :: arg2
    make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
    class(t2), intent(in) :: arg
    integer :: arg2
    make_integer_2 = arg%j * arg2
  end function make_integer_2

end module m

  use m
  class(t1), pointer :: a
  type(t2), target :: c
  a => c
  print *,a%extract(3)
  if (a%extract (3) .ne. 297) call abort        ! FAIL

end


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #25 from janus at gcc dot gnu dot org  2010-04-25 18:23 -------
I just did a full testsuite run, verifying that "dynamic_dispatch_{1-3}.f03"
are indeed the only failures with the patch in comment #23.

This means that, if we can fix the failure in comment #24, the branch will most
probably be clean, and we can finally merge back to trunk.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[paul dot richard dot thomas at gmail dot com]

------- Comment #26 from paul dot richard dot thomas at gmail dot com  2010-04-25 18:28 -------
Subject: Re:  [fortran-dev Regression] ICE: segmentation 
        fault

Dear Janus,

I thought that I would lend a helping hand, so I applied your latest
patch to my fortran-dev.  Since I had left some of my array reference
development in place, it failed to apply on

***************
*** 2486,2492 ****
      not to the class declared type.  */
    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
    gcc_assert (vtab);
-   gfc_trans_assign_vtab_procs (&parmse->pre, vtab);
    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
    gfc_add_modify (&parmse->pre, ctree,
                  fold_convert (TREE_TYPE (ctree), tmp));
--- 2486,2492 ----
      not to the class declared type.  */
    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
    gcc_assert (vtab);
+   gfc_trans_assign_vtab_procs (&parmse->pre, e->ts.u.derived, vtab);
    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
    gfc_add_modify (&parmse->pre, ctree,
                  fold_convert (TREE_TYPE (ctree), tmp));

Since this was a compilable source, even with the failure, I decided
to build it anyway. Lo and behold, the regressions have gone :-)

It's just now regtesting.

Please find the whole diff attached.

I hope that this helps.

Cheers

Paul


------- Comment #27 from paul dot richard dot thomas at gmail dot com  2010-04-25 18:28 -------
Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view)


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[paul dot richard dot thomas at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]



------- Comment #28 from paul dot richard dot thomas at gmail dot com  2010-04-25 18:59 -------
Subject: Re:  [fortran-dev Regression] ICE: segmentation 
        fault

Janus,

Forget all of our last exchanges - I screwed up somehow with the
patch.  This has nothing to do with your problem

Sorry

Paul

On Sun, Apr 25, 2010 at 8:27 PM, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Dear Janus,
>
> I thought that I would lend a helping hand, so I applied your latest
> patch to my fortran-dev.  Since I had left some of my array reference
> development in place, it failed to apply on
>
> ***************
> *** 2486,2492 ****
>      not to the class declared type.  */
>    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
>    gcc_assert (vtab);
> -   gfc_trans_assign_vtab_procs (&parmse->pre, vtab);
>    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
>    gfc_add_modify (&parmse->pre, ctree,
>                  fold_convert (TREE_TYPE (ctree), tmp));
> --- 2486,2492 ----
>      not to the class declared type.  */
>    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
>    gcc_assert (vtab);
> +   gfc_trans_assign_vtab_procs (&parmse->pre, e->ts.u.derived, vtab);
>    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
>    gfc_add_modify (&parmse->pre, ctree,
>                  fold_convert (TREE_TYPE (ctree), tmp));
>
> Since this was a compilable source, even with the failure, I decided
> to build it anyway. Lo and behold, the regressions have gone :-)
>
> It's just now regtesting.
>
> Please find the whole diff attached.
>
> I hope that this helps.
>
> Cheers
>
> Paul
>


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

------- Comment #29 from sfilippone at uniroma2 dot it  2010-04-25 19:16 -------
(In reply to comment #27)
> Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view) [edit]
> 
Tried this patch: compilation goes past the previous point, so we made
progress.
My library build stops later with 

psb_ssymbmm.f90: In function 'psb_ssymbmm':
psb_ssymbmm.f90:88:0: error: statement makes a memory store, but has no VDEFS
c_7.a.$data = 0B;
psb_ssymbmm.f90:88:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [psb_ssymbmm.o] Error 1

Does it ring a bell ? If this is not an obvious duplicate of some other issue,
I'll open a PR (tomorrow....) 


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #30 from janus at gcc dot gnu dot org  2010-04-25 19:50 -------
(In reply to comment #29)
> (In reply to comment #27)
> > Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view) [edit]
> > 
> Tried this patch: compilation goes past the previous point, so we made
> progress.
> My library build stops later with 

Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try
the patch in comment #23, which is clean (except for a small regression) and
fixes your original problem. Does this give the same error on your code?


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #31 from janus at gcc dot gnu dot org  2010-04-25 20:17 -------
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:

--- c24.dump.unpatched  2010-04-25 22:03:44.418204091 +0200
+++ c24.dump.patched    2010-04-25 21:55:50.500619202 +0200
@@ -27,7 +27,7 @@ MAIN__ ()
   if (vtab$t2.make_integer == 0B)
     {
       vtab$t2.make_integer = (integer(kind=4) (*<T434>) (void)) make_integer;
-      vtab$vtype$t2$extract.make_integer = make_integer_2;
+      vtab$vtype$t2$extract.make_integer = (integer(kind=4) (*<T43f>) (struct
.class.t2 & restrict, integer(kind=4) & restrict)) make_integer;
       vtab$t2.extract = &vtab$vtype$t2$extract;
       vtab$t2.make_integer_2 = (integer(kind=4) (*<T434>) (void))
make_integer_2;
     }


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

------- Comment #32 from sfilippone at uniroma2 dot it  2010-04-25 20:20 -------
(In reply to comment #30)
> 
> Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try
> the patch in comment #23, which is clean (except for a small regression) and
> fixes your original problem. Does this give the same error on your code?
> 
Actually I tried both, and both give the same error. The obvious question is
whether this is related to the patch or not.
I really look forward to the merge into trunk, and I would prefer reporting the
new bug against trunk. 


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #33 from janus at gcc dot gnu dot org  2010-04-25 21:44 -------
Created an attachment (id=20488)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488&action=view)
patch v5

The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of regressions in class_*, dynamic_* and
typebound_*. Will do a full testsuite run now.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20482|0                           |1
        is obsolete|                            |
  Attachment #20484|0                           |1
        is obsolete|                            |
  Attachment #20485|0                           |1
        is obsolete|                            |
  Attachment #20486|0                           |1
        is obsolete|                            |


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #34 from janus at gcc dot gnu dot org  2010-04-25 22:26 -------
(In reply to comment #33)
> Will do a full testsuite run now.

The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

------- Comment #35 from dominiq at lps dot ens dot fr  2010-04-26 08:23 -------
> The testsuite completed cleanly, without any failures. Paul, if you agree that
> this patch is ok, I can commit it tomorrow.

Confirmed without any problem on my own test.


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

------- Comment #36 from janus at gcc dot gnu dot org  2010-04-26 09:08 -------
Subject: Bug 42274

Author: janus
Date: Mon Apr 26 09:07:26 2010
New Revision: 158721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158721
Log:
2010-04-26  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc'
        attribute for all PPC members of the vtypes.
        (copy_vtab_proc_comps): Copy the correct interface.
        * trans.h (gfc_trans_assign_vtab_procs): Modified prototype.
        * trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as
        a dummy argument and make sure all PPC members of the vtab are
        initialized correctly.
        (gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument
        in call to gfc_trans_assign_vtab_procs.
        * trans-stmt.c (gfc_trans_allocate): Ditto.

2010-04-26  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * gfortran.dg/class_15.f03: New.

Added:
    branches/fortran-dev/gcc/testsuite/gfortran.dg/class_15.f03
Modified:
    branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
    branches/fortran-dev/gcc/fortran/symbol.c
    branches/fortran-dev/gcc/fortran/trans-expr.c
    branches/fortran-dev/gcc/fortran/trans-stmt.c
    branches/fortran-dev/gcc/fortran/trans.h
    branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

------- Comment #37 from pault at gcc dot gnu dot org  2010-04-26 10:57 -------
I think that we can mark this as closed.

Thanks, first to Salvatore for the report and second to Janus for the fix.

Salvatore, to repeat Janus's request, could you please check that there are no
further regressions, relative to trunk?  I am aiming to synchronise the two
trees later on this week.

Thanks again for all the efforts

Paul 


-- 

pault at gcc dot gnu dot org changed:

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


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

------- Comment #38 from pault at gcc dot gnu dot org  2010-04-29 19:11 -------
Subject: Bug 42274

Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43896
        * symbol.c (add_proc_component,copy_vtab_proc_comps): Remove
        initializers for PPC members of the vtabs.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc'
        attribute for all PPC members of the vtypes.
        (copy_vtab_proc_comps): Copy the correct interface.
        * trans.h (gfc_trans_assign_vtab_procs): Modified prototype.
        * trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as
        a dummy argument and make sure all PPC members of the vtab are
        initialized correctly.
        (gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument
        in call to gfc_trans_assign_vtab_procs.
        * trans-stmt.c (gfc_trans_allocate): Ditto.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/43326
        * resolve.c (resolve_typebound_function): Renamed
        resolve_class_compcall.Do all the detection of class references
        here.
        (resolve_typebound_subroutine): resolve_class_typebound_call
        renamed. Otherwise same as resolve_typebound_function.
        (gfc_resolve_expr): Call resolve_typebound_function.
        (resolve_code): Call resolve_typebound_subroutine.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43492
        * resolve.c (resolve_typebound_generic_call): For CLASS methods
        pass back the specific symtree name, rather than the target
        name.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42353
        * resolve.c (resolve_structure_cons): Make the initializer of
        the vtab component 'extends' the same type as the component.

2010-04-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/42680
        * interface.c (check_interface1): Pass symbol name rather than NULL to
        gfc_compare_interfaces.(gfc_compare_interfaces): Add assert to
        trap MULL. (gfc_compare_derived_types): Revert previous change
        incorporated incorrectly during merge from trunk, r155778.
        * resolve.c (check_generic_tbp_ambiguity): Pass symbol name rather
        than NULL to gfc_compare_interfaces.
        * symbol.c (add_generic_specifics): Likewise.

2010-02-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42353
        * interface.c (gfc_compare_derived_types): Add condition for vtype.
        * symbol.c (gfc_find_derived_vtab): Sey access to private.
        (gfc_find_derived_vtab): Likewise.
        * module.c (ab_attribute): Add enumerator AB_VTAB.
        (mio_symbol_attribute): Use new attribute, AB_VTAB.
        (check_for_ambiguous): Likewise.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>
            Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41829
        * trans-expr.c (select_class_proc): Remove function.
        (conv_function_val): Delete reference to previous.
        (gfc_conv_derived_to_class): Add second argument to the call to
        gfc_find_derived_vtab.
        (gfc_conv_structure): Exclude proc_pointer components when
        accessing $data field of class objects.
        (gfc_trans_assign_vtab_procs): New function.
        (gfc_trans_class_assign): Add second argument to the call to
        gfc_find_derived_vtab.
        * symbol.c (gfc_build_class_symbol): Add delayed_vtab arg and
        implement holding off searching for the vptr derived type.
        (add_proc_component): New function.
        (add_proc_comps): New function.
        (add_procs_to_declared_vtab1): New function.
        (copy_vtab_proc_comps): New function.
        (add_procs_to_declared_vtab): New function.
        (void add_generic_specifics): New function.
        (add_generics_to_declared_vtab): New function.
        (gfc_find_derived_vtab): Add second argument to the call to
        gfc_find_derived_vtab. Add the calls to
        add_procs_to_declared_vtab and add_generics_to_declared_vtab.
        * decl.c (build_sym, build_struct): Use new arg in calls to
        gfc_build_class_symbol.
        * gfortran.h : Add vtype bitfield to symbol_attr. Remove the
        definition of struct gfc_class_esym_list. Modify prototypes
        of gfc_build_class_symbol and gfc_find_derived_vtab.
        * trans-stmt.c (gfc_trans_allocate): Add second argument to the
        call to gfc_find_derived_vtab.
        * module.c : Add the vtype attribute.
        * trans.h : Add prototype for gfc_trans_assign_vtab_procs.
        * resolve.c (resolve_typebound_generic_call): Add second arg
        to pass along the generic name for class methods.
        (resolve_typebound_call): The same.
        (resolve_compcall): Use the second arg to carry the generic
        name from the above. Remove the reference to class_esym.
        (check_members, check_class_members, resolve_class_esym,
        hash_value_expr): Remove functions.
        (resolve_class_compcall, resolve_class_typebound_call): Modify
        to use vtable rather than member by member calls.
        (gfc_resolve_expr): Modify second arg in call to
        resolve_compcall.
        (resolve_select_type): Add second arg in call to
        gfc_find_derived_vtab.
        (resolve_code): Add second arg in call resolve_typebound_call.
        (resolve_fl_derived): Exclude vtypes from check for late
        procedure definitions. Likewise for checking of explicit
        interface and checking of pass arg.
        * iresolve.c (gfc_resolve_extends_type_of): Add second arg in
        calls to gfc_find_derived_vtab.
        * match.c (select_type_set_tmp): Use new arg in call to
        gfc_build_class_symbol.
        * trans-decl.c (gfc_get_symbol_decl): Complete vtable if
        necessary.
        * parse.c (endType): Finish incomplete classes.


2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * gfortran.dg/class_16.f03: New test.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * gfortran.dg/class_15.f03: New.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/43326
        * gfortran.dg/dynamic_dispatch_9.f03: New test.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43492
        * gfortran.dg/generic_22.f03 : New test.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42353
        * gfortran.dg/class_14.f03: New test.

2010-04-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/42680
        * gfortran.dg/interface_32.f90: New test.

2009-04-29  Paul Thomas  <pault@gcc.gnu.org>
            Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41829
        * gfortran.dg/dynamic_dispatch_5.f03 : Change to "run".
        * gfortran.dg/dynamic_dispatch_7.f03 : New test.
        * gfortran.dg/dynamic_dispatch_8.f03 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_14.f03
    trunk/gcc/testsuite/gfortran.dg/class_15.f03
    trunk/gcc/testsuite/gfortran.dg/class_16.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_8.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03
    trunk/gcc/testsuite/gfortran.dg/generic_22.f03
    trunk/gcc/testsuite/gfortran.dg/interface_32.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/iresolve.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03


-- 


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