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.
Created attachment 19223 [details] test case
Fortran people - if you want to use bugzilla for fortran-dev please add a fortran-dev version people can report bugs against.
The code compiles with [trunk revision 154654]. It looks like a regression.
(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
> (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
(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.
(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 ();
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
(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
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.
(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?
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
(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
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);
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 ()
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
Created attachment 20482 [details] 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
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
Created attachment 20484 [details] 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
(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
> 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.
(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.
Created attachment 20485 [details] patch v4 The attached update of the patch removes the ICEs in typebound_operator_{3,4}.f03.
(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
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.
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
Created attachment 20486 [details] check2504.diff
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 >
(In reply to comment #27) > Created an attachment (id=20486) [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....)
(In reply to comment #29) > (In reply to comment #27) > > Created an attachment (id=20486) [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?
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; }
(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.
Created attachment 20488 [details] 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.
(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.
> 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.
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
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
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