This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH], PowerPC IEEE 128-bit patch #4
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <dje dot gcc at gmail dot com>
- Date: Mon, 3 Aug 2015 21:18:36 +0000
- Subject: Re: [PATCH], PowerPC IEEE 128-bit patch #4
- Authentication-results: sourceware.org; auth=none
- References: <20150729200428 dot GA30347 at ibm-tiger dot the-meissners dot org> <alpine dot DEB dot 2 dot 10 dot 1507310041540 dot 8408 at digraph dot polyomino dot org dot uk> <20150803190231 dot GA27569 at ibm-tiger dot the-meissners dot org>
On Mon, 3 Aug 2015, Michael Meissner wrote:
> The intention of theese changes (currently unwritten) is to change the existing
> problematical names that use TF in their name to be something else, and provide
> via a weak reference an alias for the old name. So if for example, we change
> the default in GCC 7.0, code compiled by GCC 6.0 would work because it uses say
> __gcc_ltoq to call convert a 64-bit integer to IBM extended double instead of
> __floatditf. Older code that refers to __floatditf would still work fine.
But as those names are in the implementation namespace and aren't
user-visible, I don't see the point in such a change (other than as part
of a complete new incompatible ABI which gets its own copies of libgcc,
libstdc++, libc, libm and other affected libraries). Of course it *can*
be done via symbol versioning to keep working with existing binaries /
shared libraries using the existing symbols from libgcc, but the libgcc
build system doesn't make that sort of target-specific symbol versioning
particularly convenient. And as usual with symbol versioning, you'd break
compatibility with existing static libraries / .o files.
--
Joseph S. Myers
joseph@codesourcery.com