[Bug target/36669] Wrong versioning for __float128

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from joseph at codesourcery dot com  2008-06-30 19:30 -------
Subject: Re:  Wrong versioning for __float128

On Mon, 30 Jun 2008, ian at airs dot com wrote:

> The three symbols __gttf2, __lttf2, and __netf2 are part of the standard libgcc
> interface at version GCC_3.0.  The fact that they are not supported by all
> instances of libgcc on all platforms seems to me to be irrelevant.  When we
> provide those symbols, we should provide them at version GCC_3.0.
> 
> If we change the interface, then we should change the version.  But if the
> symbols are merely not present, then it is not necessary to change the version.
>  The program will get an error either way.  If we follow a different procedure,
> then we need to create different version scripts for each target.  And that is
> unlikely to work effectively.
> 
> config/i386/libgcc-x86_64-glibc.ver and config/libgcc-glibc.ver are problematic
>  because people fail to update them when libgcc-std.ver is updated.
> 
> At least, that is how it seems to me.  I don't know if this answers your
> question, because I'm not sure what you are asking.

The way it seems to me is that the practice so far has been that the 
versions do depend on the target - there are lots of target-specific 
version scripts, covering both target-specific symbols and the 
target-specific versions at which target-independent symbols were added.  
For example, the various GNU/Linux targets that underwent a transition in 
long double size have linker scripts to give appropriate versions to their 
TFmode symbols.  This is in accord with the practice followed by glibc: if 
a symbol was accidentally not exported on a given target, it will be given 
the version number of the version in which it was finally exported on that 
target (see the handling of exp2l, for example).

This means that the error tells you what version of libgcc is needed to 
get a particular symbol, and that the set of symbols in a version (for a 
given target) should not be changed once that GCC version is released.

The special version scripts do not need to be updated when libgcc-std.ver 
is updated.  They only need to be updated when the target to which they 
apply gains new symbols that are target-specific or that were added to 
libgcc-std.ver for other targets in an earlier version, which is rarer.

On this basis, the issue is that we have a bug that some TFmode symbols 
were not put in GCC_4.3.0 on x86_64 although they were newly added there, 
and the question is whether we keep them in GCC_3.0 having released with 
them there, or move them to GCC_4.3.0 for consistency with the other 
TFmode symbols (breaking any x86_64 binaries built with 4.3.0 or 4.3.1 
using __float128 and shared libgcc that use one of those symbols).


-- 


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