This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi all, here is another small OOP wrong-code patch (fixing comment #27 of the aforementioned PR). All it does is to make sure a vtab is generated for modules like this: module mod1 type :: t1 contains procedure, nopass :: get => my_get end type contains integer function my_get() my_get = 1 end function end module Usually we only build a vtab once we find a CLASS variable. In this module we have no CLASS variable (due to NOPASS), but still we need a vtab. Therefore we generate one in 'resolve_typebound_procedures', which in turn guarantees that we initialize the TBP pointer with the right procedure. The second hunk was needed fix a testsuite regression. The only testsuite failure I see with this patch is 'float128_1.f90', which surely has a different origin. Ok for trunk? Cheers, Janus 2010-08-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42769 * resolve.c (resolve_structure_cons): For derived types, make sure the type has been resolved. (resolve_typebound_procedures): Make sure the vtab has been generated. 2010-08-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42769 * gfortran.dg/dynamic_dispatch_11.f03: New.
Attachment:
pr42769.diff
Description: Binary data
Attachment:
dynamic_dispatch_11.f03
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |