[Bug fortran/59654] New: Broken function table with complex OO use case

["Thomas.L.Clune at nasa dot gov" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 59654
           Summary: Broken function table with complex OO use case
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Thomas.L.Clune at nasa dot gov

Created attachment 31553
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31553&action=edit
Reproducer  - single file.

I have an application (pFUnit) which makes very heavy use of OO fortran
features.  A recent mod has revealed that the implementation is very fragile
with regard to gfortran (4.8.1, 4.8.2, and 4.9.0).    I have discussed this
situation with Damian Rousson, and he is also somewhat surprised as to how
sensitive the compiler is in this situation.   (I should add, that this code
and the various workarounds I've tried in the real application all appear to
work correctly with both Intel and NAG compilers.)

I am attaching a simplified reproducer that exhibits some of the symptoms as
well as a UML diagram to help understand what is going on.  The reproducer
actually has very few executable lines, but involves the collaboration of at
least 3 nontrivial design patterns.  The reproducer compiles, but will
self-diagnose an incorrect execution with the string 'Error - incorrect number
of tests were run.'  If the PRIVATE statement on line 144 is uncommented, then
the code will run successfully producing the message 'Successful run'.   Using
gdb, it appears that the code somehow prematurely returns to main.     

In the full application (not attached), I've seen even more surprising behavior
which still falls into the category of an apparently damaged function pointer
table for at least one class.   Namely, gdb is showing that the code is failing
inside a method (type-bound procedure) that is not referenced _anywhere_ in the
application!  Various workarounds have moved the problem to at least 3
different methods that are never referenced.  

I have workarounds for the full application that run "correctly" but the
slightest change brings problems right back, so I'm unwilling to commit to
further development until I have a more robust solution.  Note - I'm as happy
with a robust workaround as I am with a compiler fix in this case.