[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to janus from comment #12) > - /* Make sure the vtab has been generated. */ > - gfc_find_derived_vtab (derived); This line was added in r163631, which was my fix for PR 42769.
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #12 from janus at gcc dot gnu.org --- The following patch fixes all three test cases (comment 0, 9 and 11), and is free of testsuite regressions: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 206273) +++ gcc/fortran/resolve.c(working copy) @@ -11903,9 +11903,6 @@ resolve_typebound_procedures (gfc_symbol* derived) resolve_bindings_derived = derived; resolve_bindings_result = true; - /* Make sure the vtab has been generated. */ - gfc_find_derived_vtab (derived); - if (derived->f2k_derived->tb_sym_root) gfc_traverse_symtree (derived->f2k_derived->tb_sym_root, &resolve_typebound_procedure);
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 janus at gcc dot gnu.org changed: What|Removed |Added Attachment #31557|0 |1 is obsolete|| --- Comment #11 from janus at gcc dot gnu.org --- Created attachment 31560 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31560&action=edit further reduced test case Here is a further reduced test case. The behavior is the same as before, but it is extremely shaky. Adding or removing completely unused statements will influence the runtime behavior. Classical Heisenbug.
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #10 from Harald Anlauf --- (In reply to janus from comment #9) > Created attachment 31557 [details] > reduce test case > > Reduced test case. Should print '1' and does so with 4.7.4, but prints '0' > with 4.8 and trunk. ICEs with 4.6. The reduced test case also prints '1' with 4.5.0 (rev. 160292).
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #9 from janus at gcc dot gnu.org --- Created attachment 31557 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31557&action=edit reduce test case Reduced test case. Should print '1' and does so with 4.7.4, but prints '0' with 4.8 and trunk. ICEs with 4.6.
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 tlcclt changed: What|Removed |Added Attachment #31554|0 |1 is obsolete|| --- Comment #8 from tlcclt --- Created attachment 31556 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31556&action=edit Updated UML diagram I've updated/corrected the UML. Previous version omitted the ConcreteSurrogate class and had some of the associations off. New version also reflects all has-a relationships.
[Bug fortran/59654] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-01 CC||janus at gcc dot gnu.org Summary|Broken function table with |[OOP] Broken function table |complex OO use case |with complex OO use case Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #7 from janus at gcc dot gnu.org --- I can confirm the (supposedly wrong) runtime behavior with 4.8 and trunk. 4.7 does not compile the test case. Uncommenting the private statement in line 144 only changes the behavior with 4.8, but my trunk build still yields the 'wrong' output. I tried to use -fdump-tree-original to see what changes in the generated code when flipping the private statement with 4.8, but that does not show *any* difference.
