[Bug fortran/51802] New: Duplicate mangling for OOP symbols

[Bug fortran/51802] New: Duplicate mangling for OOP symbols

[jb at gcc dot gnu.org]

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

             Bug #: 51802
           Summary: Duplicate mangling for OOP symbols
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jb@gcc.gnu.org


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.

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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)

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> 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

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 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

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Note that, in a way, this 'double mangling' is not a bug but a feature.
> ...

No feedback for more than three years. Closing as WONTFIX.