Date: Mon, 3 Oct 2022 21:02:59 +0000 From: Brooks Davis <brooks@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Brooks Davis <brooks@FreeBSD.org>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: enabling float128 support in clang? Message-ID: <20221003210259.GA83024@spindle.one-eyed-alien.net> In-Reply-To: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB@yahoo.com> References: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB.ref@yahoo.com> <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2022 at 01:36:55PM -0700, Mark Millard wrote: > Brooks Davis <brooks_at_freebsd.org> wrote on > Date: Mon, 03 Oct 2022 18:43:10 UTC : >=20 > > TL;DR: Is there a reason not to enable float128 support in clang for > > x86? > >=20 > > Due to a build breakage with the flang runtime, I recently noticed that= =20 > > unlike most other OSes we don't support float128 in clang. It's enable > > in modern GCC and other OSes have it enable in clang: > > - Hakiu 2018: https://reviews.llvm.org/D54901 > > - Solaris 2018: https://reviews.llvm.org/D41240 > > - WASM 2019: https://reviews.llvm.org/D57154 > > - Dragonfly 2021: https://reviews.llvm.org/D111760 > > - OpenBSD (history hard to find...) > >=20 > > Is there a known reason not to enable this? > >=20 > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > > GCC doesn't define it...) > >=20 > > -- Brooks > >=20 > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targ= ets/OSTargets.h > > index c75f7d9fbafe..ea95f40e81a0 100644 > > --- a/clang/lib/Basic/Targets/OSTargets.h > > +++ b/clang/lib/Basic/Targets/OSTargets.h > > @@ -232,6 +232,9 @@ protected: > > // setting this to 1 is conforming even if all the basic source > > // character literals have the same encoding as char and wchar_t. > > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > > + > > + if (this->HasFloat128) > > + Builder.defineMacro("__FLOAT128__"); > > } > > =20 > > public: > > @@ -241,6 +244,7 @@ public: > > default: > > case llvm::Triple::x86: > > case llvm::Triple::x86_64: > > + this->HasFloat128 =3D true; > > this->MCountName =3D ".mcount"; > > break; > > case llvm::Triple::mips: > >=20 > >=20 >=20 >=20 > See: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238129 >=20 > for some past exchanges on this. From comment #3: >=20 > QUOTE of Dimitry Andric: > As mentioned on the mailing list, it is not a matter of just "enabling" f= loat128. Somebody has to step up and write a BSD licensed quadmath.h, to st= art with. > END QUOTE Looking that over, I'm not sure we've made the right decision (and I don't think my reply in the thread makes sense). Right now we're in a state where we couldn't build a BSD libquadmath if one existed unless it was pure assembly which surely isn't where we want to be. That being said, it's possible that only having compiler support would be a problem due to either ports or the compiler itself using libquadmath functions once enabled, but it doesn't look like other OSes did anything about library support when they turned on basic support. -- Brooks --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjO04DAAoJEKzQXbSebgfAB50H/2SIELYsz/8kjQZl97fxyRem oKXBhOx7GCky1udcxsYIbUMFNwNLnPQ+o0g+aB3C2XnbaQJmWMrzbpnUG6Jv1Ap1 FAWubFAQVaDYDMRiOg7rm7/SVk035eIfQPEeAGa8bfayJAeV3JedWH0KEYdtqbF/ wN/Oo//Z26NfyKyrEfVLPuYznrB4pXEiiDnkC0CzMWFwZzgrIaPtdE5XETJ/pMAA yUx1Fj3kBw284WGTOK+F34Njr2JJAKYK7NGuVT9iPqqo6vxD+OUBRsvYwPaU7VnE vn0sT3zj5S1u5DPHwgHe8528bBen7wUmIO1LW/pOYflv6nuFr8kjjPtxk2T3xww= =w1zb -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221003210259.GA83024>