Bug 51802 - [OOP] Duplicate mangling for OOP symbols
Summary: [OOP] Duplicate mangling for OOP symbols
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-09 20:46 UTC by Janne Blomqvist
Modified: 2012-10-04 13:44 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janne Blomqvist 2012-01-09 20:46:53 UTC
Compiling the last example with type-bound procedures at 

http://fortranwiki.org/fortran/show/Object-oriented+programming

and looking at the symbols generated in the binary, there is some duplication of names, making the symbols longer than they need to be. From the "nm -s" output:

0804869f T __class_circle_MOD___copy_class_circle_Circle
0804a050 B __class_circle_MOD___def_init_class_circle_Circle
0804a028 D __class_circle_MOD___vtab_class_circle_Circle

That is, "class_circle", the name of the module, appears twice.
Comment 1 Tobias Burnus 2012-03-20 08:42:11 UTC
That that changing this will break the ABI. Thus, it can only be done when we have to break the ABI. That will happen for the new array descriptor.

(This bug is listed at http://gcc.gnu.org/wiki/LibgfortranAbiCleanup)
Comment 2 Paul Thomas 2012-03-20 10:52:45 UTC
(In reply to comment #1)
> That that changing this will break the ABI. Thus, it can only be done when we
> have to break the ABI. That will happen for the new array descriptor.
> 
> (This bug is listed at http://gcc.gnu.org/wiki/LibgfortranAbiCleanup)

I agree completely.  However, once 4.7 is released, should we be excessively pristine about ABI breakage in trunk?  It is, after all, the development version and, to some degree, if people use the development version for production code they should be mindful of the risks....

Cheers

Paul
Comment 3 Tobias Burnus 2012-03-20 11:22:37 UTC
(In reply to comment #2)
> I agree completely.  However, once 4.7 is released, should we be excessively
> pristine about ABI breakage in trunk?  It is, after all, the development
> version and, to some degree, if people use the development version for
> production code they should be mindful of the risks....

Well, the point is that code (e.g. libraries) compiled with GCC 4.3/4.4/4.5/4.6/4.7 shall be linkable with code compiled with GCC 4.8.

In particular, ABI changes relative to Fortran 77 ABIs should be avoided. (libblas, liblapack, ...) - as they are truly used with many applications and as there also no .mod file is involved.

For experimental code - such as -fcoarray=lib -, we have more leeway, but for code which is used in production, we shouldn't break the ABI.

As the .mod format changes with every release, the chance that the user runs into ABI problems is a bit reduced as for type declarations, one has to recompile to get a new .mod file. However, one can still construct cases where ABI issues also occur in that case. (libA and libB compiled with 4.7; libB uses libA; libA recompiled with 4.8 and then linking libA, libB and the application. If libA and libB use a feature for which the ABI has changed, it will break at link or run time.)

The g++ compiler - where the .mod issue does not exist and where many more application use C++ libraries, the ABI issue is much greater. g++ has the -fabi-version=... flag to toggle between different ABIs and -Wabi to warn about such issues.


In case of the new array descriptor, the ABI change is so big and affecting  many programs, that it cannot be avoided. Thus, doing so, bumping the .so version number and using the opportunity for a clean up should be done. However, afterwards, we have to try hard to avoid any ABI breakage and it would be good if .mod files from a previous compiler version would continue to work. Thus, we should either have the modifications in an upward compatible way - or we should build in some way to read old versions, by explicitly skipping new features during read in. (As we know the version number - we can make use of it!) The .mod part is not an issue for the first version with the new descriptor - as we have to break the ABI.

If we include the new array descriptor in 4.8, I think for 4.9 we should already have the policy that no module.c change is allowed, unless it is done such that .mod files from 4.8 continue to work.
Comment 4 janus 2012-10-04 13:44:45 UTC
Note that, in a way, this 'double mangling' is not a bug but a feature.

It was introduced for PR 46313, in order to handle cases like the one below. (There might be other ways to deal with this, though.)


module m1
  implicit none
  type mytype
  end type mytype
  type,extends(mytype) :: mytype2
    integer :: a(10) = 2
  end type mytype2
contains
  subroutine test1()
    class(mytype), allocatable :: a1, a2
    allocate (a1, source=mytype2())
    allocate ( a2, source=a1)
    select type (a2)
      type is (mytype2)
        print *, a2%a
    end select
    deallocate  (a2)
    allocate ( a2, mold=a1)
    select type (a2)
      type is (mytype2)
        print *, a2%a
    end select
  end subroutine test1
end module m1

module m2
  implicit none
  type mytype
  end type mytype
  type,extends(mytype) :: mytype2
    integer :: b(10) = 8
  end type mytype2
contains
  subroutine test2()
    class(mytype), allocatable :: b1, b2
    allocate (b1, source=mytype2())
    allocate ( b2, source=b1)
    select type (b2)
      type is (mytype2)
        print *, b2%b
    end select
    deallocate  (b2)
    allocate ( b2, mold=b1)
    select type (b2)
      type is (mytype2)
        print *, b2%b
    end select
  end subroutine test2
end module m2

use m1, only: test1
use m2, only: test2
implicit none
call test1()
call test2()
end