summaryrefslogtreecommitdiff
path: root/tune
diff options
context:
space:
mode:
authorvlefevre <vlefevre@280ebfd0-de03-0410-8827-d642c229c3f4>2018-02-26 12:43:22 +0000
committervlefevre <vlefevre@280ebfd0-de03-0410-8827-d642c229c3f4>2018-02-26 12:43:22 +0000
commit9c3ef96c39a37457ee7d3c04419ccfdc1e76dd4c (patch)
tree069b35a5c32d70d9b1b7a0d30c0ce3780df85d2f /tune
parente1a70eb11589eaa5ac694ece28607f9355379c0a (diff)
downloadmpfr-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