* [Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
2012-01-09 20:47 [Bug fortran/51802] New: Duplicate mangling for OOP symbols jb at gcc dot gnu.org
@ 2012-03-20 8:43 ` burnus at gcc dot gnu.org
2012-03-20 10:55 ` pault at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-20 8:43 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
2012-01-09 20:47 [Bug fortran/51802] New: Duplicate mangling for OOP symbols jb at gcc dot gnu.org
2012-03-20 8:43 ` [Bug fortran/51802] [OOP] " burnus at gcc dot gnu.org
@ 2012-03-20 10:55 ` pault at gcc dot gnu.org
2012-03-20 11:26 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pault at gcc dot gnu.org @ 2012-03-20 10:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
2012-01-09 20:47 [Bug fortran/51802] New: Duplicate mangling for OOP symbols jb at gcc dot gnu.org
2012-03-20 8:43 ` [Bug fortran/51802] [OOP] " burnus at gcc dot gnu.org
2012-03-20 10:55 ` pault at gcc dot gnu.org
@ 2012-03-20 11:26 ` burnus at gcc dot gnu.org
2012-10-04 13:45 ` janus at gcc dot gnu.org
2015-10-13 16:34 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-20 11:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
2012-01-09 20:47 [Bug fortran/51802] New: Duplicate mangling for OOP symbols jb at gcc dot gnu.org
` (2 preceding siblings ...)
2012-03-20 11:26 ` burnus at gcc dot gnu.org
@ 2012-10-04 13:45 ` janus at gcc dot gnu.org
2015-10-13 16:34 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-04 13:45 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
2012-01-09 20:47 [Bug fortran/51802] New: Duplicate mangling for OOP symbols jb at gcc dot gnu.org
` (3 preceding siblings ...)
2012-10-04 13:45 ` janus at gcc dot gnu.org
@ 2015-10-13 16:34 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-10-13 16:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread