Since clang supports it and there is no equivalent 128-bit type currently supported by clang, please enable it. In the current ML conversation it has been revealed: "But from clang's OSTargets.h file, it looks like 128 bit float support is never set to enabled for FreeBSD." [1] --References-- [1] hackers@ thread: https://lists.freebsd.org/pipermail/freebsd-hackers/2019-May/054660.html
Is there some reason the compiler should emulate a floating point mode that doesn't exist on any hardware, rather than using a separate library like MPFR?
(In reply to Conrad Meyer from comment #1) IMO, this question should be directed to the clang team. Once they have some feature we shouldn't be second guessing their judgement.
As mentioned on the mailing list, it is not a matter of just "enabling" float128. Somebody has to step up and write a BSD licensed quadmath.h, to start with.
Created attachment 213010 [details] New experimental port of math/libquadmath (In reply to Dimitry Andric from comment #3) Do you only need the header, or is the whole library required? The Gcc libquadmath is released under LGPL 2.1 I do no think that it should be in base, but it is easy to get it in our ports tree: please see the attached patch. Remarks: - this is not a perfect solution, because some Gcc compiler is needed to build it, but no problem if only the header is requested; - a distfile from the GitHub mirror is used, but we could take a released tarball directly from GNU, or even build our own smaller tarball with only the minimum bits. Is this sufficient to enable the support of float128 in the port devel/llvm10?
If libquadmath needs gcc then we'd probably want to make clang support be off by default. I don't think we want to add gcc as a dependency of clang.
Created attachment 214150 [details] New experimental port of math/libquadmath (In reply to Brooks Davis from comment #5) According to your answer, it seems that the header is not sufficient and the whole library is requested. This new attachment removes 'USE_GCC', but of course it fails with clang: libtool: compile: cc -DHAVE_CONFIG_H -I. -I ./../include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT math/fmodq.lo -MD -MP -MF math/.deps/fmodq.Tpo -c math/fmodq.c -fPIC -DPIC -o math/.libs/fmodq.o In file included from math/acoshq.c:30: In file included from ./quadmath-imp.h:29: ./quadmath.h:33:39: error: unsupported machine mode 'TC' typedef _Complex float __attribute__((mode(TC))) __complex128; ^ ./quadmath.h:47:26: error: __float128 is not supported on this target extern __float128 acosq (__float128) __quadmath_throw; ^ ./quadmath.h:47:8: error: __float128 is not supported on this target extern __float128 acosq (__float128) __quadmath_throw; ^ ./quadmath.h:48:27: error: __float128 is not supported on this target … If the support of 128 bits float get enabled, as suggested in comment #1, could this compile?
I think it's necessary to enable this __float128 in order to have a hope of a runtime (since we can't compile one without it). I've created https://reviews.llvm.org/D135171 to enable compiler support.
The Driver has had float128 support enabled for 17.0.6. compiler-rt has had the float128 functions added to ToT and will be released with 18.