Re: enabling float128 support in clang?

Brooks Davis <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
On Tue, Oct 04, 2022 at 03:57:39PM +0000, Brooks Davis wrote:
> On Tue, Oct 04, 2022 at 04:02:05PM +0100, Alexander Richardson wrote:
> > On Mon, 3 Oct 2022 at 19:43, Brooks Davis <[email protected]> wrote:
> > >
> > > TL;DR: Is there a reason not to enable float128 support in clang for
> > > x86?
> > >
> > > Due to a build breakage with the flang runtime, I recently noticed that
> > > 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...)
> > >
> > > Is there a known reason not to enable this?
> > >
> > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as
> > > GCC doesn't define it...)
> > >
> > > -- Brooks
> > >
> > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/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__");
> > >    }
> > >
> > >  public:
> > > @@ -241,6 +244,7 @@ public:
> > >      default:
> > >      case llvm::Triple::x86:
> > >      case llvm::Triple::x86_64:
> > > +      this->HasFloat128 = true;
> > >        this->MCountName = ".mcount";
> > >        break;
> > >      case llvm::Triple::mips:
> > >
> > 
> > I think this makes sense and may even motivate me to try and get the
> > necessary library calls merged to compiler-rt
> > (https://reviews.llvm.org/D98261).
> 
> Sounds good. I'll submit a review.

https://reviews.llvm.org/D98261

-- Brooks
signature.asc (application/pgp-signature, 455 B)
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJjPFnAAAoJEKzQXbSebgfAOp8IAJxiHSDSDfoLEPJeofqWePuD
f/pGVUu5OQTJ2+QxvDPkAqPvX/bDsBKCzCQ1bsNoBWMGsilTVO1MoLsXvuVZMmcM
PhiYcZEgnQdJ84XSOnCYzqL35r1u2GgpWvbxqJFqdIB2bkx+sVbdMMbrx1TtRjhs
JDzbx+ARE0A9qMQepw+sQb/lC5I/Q311OZXxBcoucA8JFI8YtECk59BrAGN7munP
s0smDXobexPpw8lXj7IoYyX8Um7QuT6Zm41aAQMZp/esEzq3ZDoFbHsERMyPRvQZ
BLo7vKwFUyeXO4AfWWnEvkRIaKI9XT0XcKnUOqxyrfeai4BWiNkqktGk6uaHcMo=
=M5Qr
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.