On 26.06.2017 18:01, Thor Lancelot Simon wrote: > On Sat, Jun 24, 2017 at 11:27:47AM +0200, Martin Husemann wrote: >> On Fri, Jun 23, 2017 at 10:27:40PM +0200, Kamil Rytarowski wrote: >>> 3. Disable float128 in libstdc++ for everybody. >> >> You are missing the obvious one: >> >> 4. Disable float128 for all architectures that have no hardware support >> for it (this would basically be all 32bit ones plus a few 64bit, >> including x68_64 IIUC) and where the ABI does not require this >> format for long double (for example sparc64). >> >> Providing this format for anything else just makes no sense to me. >> The availability should not depend on the compiler used. > > I am similarly skeptical about whether we should expose a floating > point format not supported by the hardware and which is likely to > cause ill-written or ill-configured applications to run slowly with > software floating point and precision they don't actually need, > instead of quickly with hardware floating point and enough precision > already. > > Thor > I don't think this is valid in real-world. Almost 100% software we build is written for 32/64-bit x86. Almost 100% of it is developed for OSes that enable __float128. Mostly every user of __float128, takes it on purpose and they all are well aware of performance implications. In such circumstances I would give free choice to developers what to do. float128 is used in real-world software not just accidentally, but on demand - I ran into this requirement with BRL-CAD.. thankfully there was still a fallback for GCC pre-4.6 versions, without this data type. BRL-CAD checked just compiler type and assumed that __float128 is there. This is inappropriate check, but symptomatic. This code was the original purpose to enable this datatype on NetBSD. Personally I'm in favor of adding an option to users to do whatever they need to get done. Here it comes with a small cost from our side, by enabling a config option in GNU libstdc++.
Attachment:
signature.asc
Description: OpenPGP digital signature