From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13808 invoked by alias); 1 Jan 2014 01:25:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13789 invoked by uid 48); 1 Jan 2014 01:25:30 -0000 From: "Thomas.L.Clune at nasa dot gov" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/59654] New: Broken function table with complex OO use case Date: Wed, 01 Jan 2014 01:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: Thomas.L.Clune at nasa dot gov X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00001.txt.bz2 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.