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

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

[Thomas.L.Clune at nasa dot gov]

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.

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

[Thomas.L.Clune at nasa dot gov]

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

tlcclt <Thomas.L.Clune at nasa dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Thomas.L.Clune at nasa dot gov

--- Comment #1 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
Created attachment 31554
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31554&action=edit
UML Class diagram for reproducer

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|major                       |normal

--- Comment #2 from kargl at gcc dot gnu.org ---
What command line do you use and what operating system?
Can you run the application under valgrind?

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

[Thomas.L.Clune at nasa dot gov]

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

--- Comment #3 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
I have testend under OS X (10.8.5) with gfortran 4.8.1 and 4.8.2.   I've also
tested under Linux (not sure which flavor) with 4.9.0.

Command line is:

% gfortran allinone.F90
% ./a.out
 Error - incorrect number of tests were run.
%


Although I've heard of valgrind, I've never used it.


PS Sorry about how I set the "Importance" field.  I assumed it was for the
user's perspective.

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

[Thomas.L.Clune at nasa dot gov]

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

--- Comment #4 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
OK - had a bit of time waiting for the New Year countdown …  so read up a bit
on valgrind. 

A vanilla run under Linux with 4.9.0 gave the following, which seems
encouraging, albeit cryptic:

% gfortran -O0 -g allinone.F90
% valgrind ./a.out
==4724== Memcheck, a memory error detector
==4724== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4724== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4724== Command: ./a.out
==4724==
--4724-- WARNING: Serious error when reading debug info
--4724-- When reading debug info from /gpfsm/dhome/tclune/a.out:
--4724-- Ignoring non-Dwarf2/3 block in .debug_info
./a.out: error while loading shared libraries: libquadmath.so.0: cannot open
shared object file: No such file or directory
==4724== Jump to the invalid address stated on the next line
==4724==    at 0x4DE: ???
==4724==    by 0x400DEC7: _dl_signal_error (in /lib64/ld-2.11.1.so)
==4724==    by 0x400CFD2: _dl_map_object_deps (in /lib64/ld-2.11.1.so)
==4724==    by 0x40032B3: dl_main (in /lib64/ld-2.11.1.so)
==4724==    by 0x4014979: _dl_sysdep_start (in /lib64/ld-2.11.1.so)
==4724==    by 0x40013D0: _dl_start (in /lib64/ld-2.11.1.so)
==4724==    by 0x4000B07: ??? (in /lib64/ld-2.11.1.so)
==4724==  Address 0x4de is not stack'd, malloc'd or (recently) free'd
==4724==
==4724==
==4724== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==4724==  Bad permissions for mapped region at address 0x4DE
==4724==    at 0x4DE: ???
==4724==    by 0x400DEC7: _dl_signal_error (in /lib64/ld-2.11.1.so)
==4724==    by 0x400CFD2: _dl_map_object_deps (in /lib64/ld-2.11.1.so)
==4724==    by 0x40032B3: dl_main (in /lib64/ld-2.11.1.so)
==4724==    by 0x4014979: _dl_sysdep_start (in /lib64/ld-2.11.1.so)
==4724==    by 0x40013D0: _dl_start (in /lib64/ld-2.11.1.so)
==4724==    by 0x4000B07: ??? (in /lib64/ld-2.11.1.so)
==4724==
==4724== HEAP SUMMARY:
==4724==     in use at exit: 0 bytes in 0 blocks
==4724==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4724==
==4724== All heap blocks were freed -- no leaks are possible
==4724==
==4724== For counts of detected and suppressed errors, rerun with: -v
==4724== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)



Thanks for helping with this!
>From gcc-bugs-return-438869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 01 05:02:58 2014
Return-Path: <gcc-bugs-return-438869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23454 invoked by alias); 1 Jan 2014 05:02:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23425 invoked by uid 48); 1 Jan 2014 05:02:54 -0000
From: "Thomas.L.Clune at nasa dot gov" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59654] Broken function table with complex OO use case
Date: Wed, 01 Jan 2014 05:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: normal
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:
Message-ID: <bug-59654-4-3cOodWt3Ti@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00011.txt.bz2
Content-length: 2083

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

--- Comment #5 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
Ignore that output from Valgind.  I was logged out between building and
running, and failed to reload the appropriate environment.   With the correct
environment, I get a clean run from valgrind:

valgrind ./a.out
==9886== Memcheck, a memory error detector
==9886== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9886== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9886== Command: ./a.out
==9886==
--9886-- WARNING: Serious error when reading debug info
--9886-- When reading debug info from /gpfsm/dhome/tclune/a.out:
--9886-- Ignoring non-Dwarf2/3 block in .debug_info
--9886-- WARNING: Serious error when reading debug info
--9886-- When reading debug info from
/usr/local/other/SLES11.1/gcc/4.9/lib64/libgfortran.so.3.0.0:
--9886-- Ignoring non-Dwarf2/3 block in .debug_info

…

--9886-- Ignoring non-Dwarf2/3 block in .debug_info
--9886-- WARNING: Serious error when reading debug info
--9886-- When reading debug info from
/usr/local/other/SLES11.1/gcc/4.9/lib64/libquadmath.so.0.0.0:
--9886-- Ignoring non-Dwarf2/3 block in .debug_info
 Error - incorrect number of tests were run.
==9886==
==9886== HEAP SUMMARY:
==9886==     in use at exit: 1 bytes in 1 blocks
==9886==   total heap usage: 22 allocs, 21 frees, 11,835 bytes allocated
==9886==
==9886== LEAK SUMMARY:
==9886==    definitely lost: 0 bytes in 0 blocks
==9886==    indirectly lost: 0 bytes in 0 blocks
==9886==      possibly lost: 0 bytes in 0 blocks
==9886==    still reachable: 1 bytes in 1 blocks
==9886==         suppressed: 0 bytes in 0 blocks
==9886== Rerun with --leak-check=full to see details of leaked memory
==9886==
==9886== For counts of detected and suppressed errors, rerun with: -v
==9886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
>From gcc-bugs-return-438870-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 01 07:55:59 2014
Return-Path: <gcc-bugs-return-438870-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3044 invoked by alias); 1 Jan 2014 07:55:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3003 invoked by uid 55); 1 Jan 2014 07:55:54 -0000
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59654] Broken function table with complex OO use case
Date: Wed, 01 Jan 2014 07:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
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:
Message-ID: <bug-59654-4-UaU337fZEk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
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/msg00012.txt.bz2
Content-length: 639

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY654

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Jan 01, 2014 at 05:02:53AM +0000, Thomas.L.Clune at nasa dot gov wrote:
>
> Ignore that output from Valgind.  I was logged out between building and
> running, and failed to reload the appropriate environment.   With the correct
> environment, I get a clean run from valgrind:
>

I like the other trace better.  It suggested a memory corruption
problem. ;)

The trace here suggests to me that gfortran is losing a
pointer somewhere.  Unfortunately, I don't know much
about the OO parts of gfortran.

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

[janus at gcc dot gnu.org]

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.

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

[Thomas.L.Clune at nasa dot gov]

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

tlcclt <Thomas.L.Clune at nasa dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31554|0                           |1
        is obsolete|                            |

--- Comment #8 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
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

[janus at gcc dot gnu.org]

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

[anlauf at gmx dot de]

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

--- Comment #10 from Harald Anlauf <anlauf at gmx dot de> ---
(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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[OOP] Broken function table |[4.8/4.9 Regression] [OOP]
                   |with complex OO use case    |Broken function table with
                   |                            |complex OO use case

--- Comment #14 from janus at gcc dot gnu.org ---
I'm marking this PR as a regression, due to the fact that both comment 9 and
comment 11 work with 4.7, but fail with 4.8 upwards.

However, I'm not sure if 4.7 works reliably or if it is just a coincidence due
to the Heisenbuggy nature of this bug.

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to janus from comment #13)
> (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.

I just verified that removing the line does not re-introduce any problems for
the test cases in PR 42769.

I will commit the patch as obvious, given that it is really simple, only
removes code, seems to fix the problems here reliably and does not yield any
regressions.

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Jan  2 17:27:11 2014
New Revision: 206281

URL: http://gcc.gnu.org/viewcvs?rev=206281&root=gcc&view=rev
Log:
2014-01-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/59654
    * resolve.c (resolve_typebound_procedures): No need to create the vtab
    here.

2014-01-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/59654
    * gfortran.dg/dynamic_dispatch_12.f90: New.

Added:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/ChangeLog-2013
      - copied unchanged from r206280, trunk/gcc/fortran/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_12.f90
Modified:
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
After r206281, the bug should be fixed on trunk.

Thomas, if you have the possibility to test a current trunk build, it would be
great if you could verify that the problem is gone also for your full code.

(If yes, I plan to do a backport to 4.8, too.)

Cheers,
Janus

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[Thomas.L.Clune at nasa dot gov]

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

--- Comment #18 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
Hello Janus,

I usually just use mac port these days, but I will try this weekend to build
gfortran from the current trunk.  (If I fail, then I have the luxury of
assigning another person on my staff to do it on our cluster instead.)

With regard to the back port in 4.8,  would that appear only in 4.8.3?  Or
would it possibly also go into 4.8.2/4.8.1.  Just so I can plan any support
issues with my user community.

Thank you so much for such a speedy resolution.  

- Tom

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org ---
(In reply to tlcclt from comment #18)
> I usually just use mac port these days

Apparently MacPorts does have GCC trunk snapshots. Tbe current one is from
2013-12-29 and I think they are updated weekly, so you might have to wait a few
days.


> With regard to the back port in 4.8,  would that appear only in 4.8.3?  Or
> would it possibly also go into 4.8.2/4.8.1.

No, 4.8.1 and 4.8.2 have been released already. The fix would go into the
upcoming 4.8.3.


> Thank you so much for such a speedy resolution.  

Thanks for the bug report!

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[rouson at stanford dot edu]

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

--- Comment #20 from Damian Rouson <rouson at stanford dot edu> ---
FYI, the current port of gcc49 via macports is broken
(https://trac.macports.org/ticket/41964) so I think Tom’s only choice will be
to build from source or build on another platform unless the port gets fixed.

Damian




On Jan 2, 2014, at 1:59 PM, janus at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654
> 
> --- Comment #19 from janus at gcc dot gnu.org ---
> (In reply to tlcclt from comment #18)
>> I usually just use mac port these days
> 
> Apparently MacPorts does have GCC trunk snapshots. Tbe current one is from
> 2013-12-29 and I think they are updated weekly, so you might have to wait a few
> days.
> 
> 
>> With regard to the back port in 4.8,  would that appear only in 4.8.3?  Or
>> would it possibly also go into 4.8.2/4.8.1.
> 
> No, 4.8.1 and 4.8.2 have been released already. The fix would go into the
> upcoming 4.8.3.
> 
> 
>> Thank you so much for such a speedy resolution.  
> 
> Thanks for the bug report!
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
>From gcc-bugs-return-438952-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 03 00:03:00 2014
Return-Path: <gcc-bugs-return-438952-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1079 invoked by alias); 3 Jan 2014 00:02:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1060 invoked by uid 48); 3 Jan 2014 00:02:55 -0000
From: "bruck.michael at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59661] New: documentation: __builtin_FUNCTION / _FILE listed as returning int
Date: Fri, 03 Jan 2014 00:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: bruck.michael at googlemail dot com
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
Message-ID: <bug-59661-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00094.txt.bz2
Content-length: 688

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

            Bug ID: 59661
           Summary: documentation: __builtin_FUNCTION / _FILE listed as
                    returning int
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bruck.michael at googlemail dot com

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

lists:


— Built-in Function: int __builtin_FUNCTION ()
...
— Built-in Function: int __builtin_FILE ()
...

These should return some sort of string (ideally constexpr?).
>From gcc-bugs-return-438953-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 03 00:42:29 2014
Return-Path: <gcc-bugs-return-438953-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17273 invoked by alias); 3 Jan 2014 00:42:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17232 invoked by uid 48); 3 Jan 2014 00:42:25 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59661] documentation: __builtin_FUNCTION / _FILE listed as returning int
Date: Fri, 03 Jan 2014 00:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: keywords bug_status cf_reconfirmed_on cc version everconfirmed bug_severity
Message-ID: <bug-59661-4-Svstsj5NGU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59661-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59661-4@http.gcc.gnu.org/bugzilla/>
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/msg00095.txt.bz2
Content-length: 730

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY661

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-03
                 CC|                            |rguenth at gcc dot gnu.org
            Version|unknown                     |4.9.0
     Ever confirmed|0                           |1
           Severity|minor                       |normal

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #21 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Damian Rouson from comment #20)
> FYI, the current port of gcc49 via macports is broken
> (https://trac.macports.org/ticket/41964)

Why doesn't anyone report this issue? It's now tracked as PR59663

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[Thomas.L.Clune at nasa dot gov]

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

--- Comment #22 from tlcclt <Thomas.L.Clune at nasa dot gov> ---
Success!

I had to manually edit the configure file for the latest gcc to build on my
Mac.  (a few -Werror=…) were blocking the compilation.  Looks like that should
be off by default, but somehow is not.

Anyway, I was able to build the gcc. And … it _fixed_ the problem in the real
code!

Thanks so much for all the assistance.
>From gcc-bugs-return-439039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 04 14:21:34 2014
Return-Path: <gcc-bugs-return-439039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2719 invoked by alias); 4 Jan 2014 14:21:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2666 invoked by uid 48); 4 Jan 2014 14:21:29 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case
Date: Sat, 04 Jan 2014 14:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: janus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59654-4-4EPwKrEwqB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59654-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00181.txt.bz2
Content-length: 298

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

--- Comment #23 from janus at gcc dot gnu.org ---
(In reply to tlcclt from comment #22)
> Anyway, I was able to build the gcc. And … it _fixed_ the problem in the
> real code!

Great, thanks for checking. Will apply the backport soon.
>From gcc-bugs-return-439040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 04 16:16:15 2014
Return-Path: <gcc-bugs-return-439040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11040 invoked by alias); 4 Jan 2014 16:16:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11009 invoked by uid 55); 4 Jan 2014 16:16:10 -0000
From: "christos at zoulas dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail
Date: Sat, 04 Jan 2014 16:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: christos at zoulas dot com
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:
Message-ID: <bug-59674-4-rQZ2zWMljV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59674-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59674-4@http.gcc.gnu.org/bugzilla/>
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/msg00182.txt.bz2
Content-length: 648

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY674

--- Comment #2 from Christos Zoulas <christos at zoulas dot com> ---
On Jan 4, 11:20am, gcc-bugzilla@gcc.gnu.org ("mikpelinux at gmail dot com")
wrote:
-- Subject: [Bug c/59674] On m68k and vax variables stack variables with > MA

| http://gcc.gnu.org/bugzilla/show_bug.cgi?idY674
|
| --- Comment #1 from Mikael Pettersson <mikpelinux at gmail dot com> ---
| Works, as in generates OK looking code w/o issuing any diagnostics, on both
| m68k-linux and vax-linux for me.  A NetBSD issue?

Are you using a native compiler or a cross-compiler? We are using a cross
compiler from amd64.

christos

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

--- Comment #24 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Jan  4 16:47:27 2014
New Revision: 206335

URL: http://gcc.gnu.org/viewcvs?rev=206335&root=gcc&view=rev
Log:
2014-01-04  Janus Weil  <janus@gcc.gnu.org>

    Backport from mainline
    2014-01-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/59654
    * resolve.c (resolve_typebound_procedures): No need to create the vtab
    here.

2014-01-04  Janus Weil  <janus@gcc.gnu.org>

    Backport from mainline
    2014-01-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/59654
    * gfortran.dg/dynamic_dispatch_12.f90: New.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/dynamic_dispatch_12.f90
Modified:
    branches/gcc-4_8-branch/gcc/fortran/ChangeLog
    branches/gcc-4_8-branch/gcc/fortran/resolve.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #25 from janus at gcc dot gnu.org ---
Fixed for 4.9.0 and 4.8.3. Closing.

[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Why doesn't anyone report this issue? It's now tracked as PR59663

It has been pr59541 since 2013-12-18 07:46 UTC.