Re: enabling float128 support in clang?

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 :
> 
> > 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:
> > 
> > 
> 
> 
> See:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238129
> 
> for some past exchanges on this. From comment #3:
> 
> QUOTE of Dimitry Andric:
> 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.
> 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