diff options
author | vlefevre <vlefevre@280ebfd0-de03-0410-8827-d642c229c3f4> | 2018-02-26 12:43:22 +0000 |
---|---|---|
committer | vlefevre <vlefevre@280ebfd0-de03-0410-8827-d642c229c3f4> | 2018-02-26 12:43:22 +0000 |
commit | 9c3ef96c39a37457ee7d3c04419ccfdc1e76dd4c (patch) | |
tree | 069b35a5c32d70d9b1b7a0d30c0ce3780df85d2f /tune | |
parent | e1a70eb11589eaa5ac694ece28607f9355379c0a (diff) | |
download | mpfr-9c3ef96c39a37457ee7d3c04419ccfdc1e76dd4c.tar.gz |
Updated support for binary128:
* __float128 was changed to _Float128 (ISO/IEC TS 18661) in r12391;
also changed the suffix of the constants from "q" to "f128".
* Use __float128 with the "q" suffix as a fallback in order to avoid
regressions with GCC 6- and with C++ mode (g++).
As documented in the GCC manual, this is entirely compatible on most
platforms where both are supported: _Float128 and __float128 are the
same type, and it could be checked that the following prototypes are
equivalent (as expected):
_Float128 f (__float128)
__float128 f (_Float128)
The only potential issues would be on hppa and IA-64 HP-UX, where
__float128 is an alias for "long double" instead of _Float128, in
case the ABI would be different (I have no information about this)
and both would be mixed up with software using the MPFR conversion
functions for binary128 via __float128 or "long double". The worst
thing that could happen is a link error. If the link is accepted,
everything should be fine as the representation doesn't change.
git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@12444 280ebfd0-de03-0410-8827-d642c229c3f4
Diffstat (limited to 'tune')
0 files changed, 0 insertions, 0 deletions