[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250819151548.GA1827@brightrain.aerifal.cx>
Date: Tue, 19 Aug 2025 11:15:48 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: [PATCH] configure: prevent gcc and clang from
performing floating point contraction
On Sun, Aug 17, 2025 at 08:54:40AM +0200, Alex Rønne Petersen wrote:
> On Sun, Aug 17, 2025, at 05:54, Rich Felker wrote:
> > On Sat, Aug 16, 2025 at 11:09:56PM -0400, Rich Felker wrote:
> >> On Sat, Aug 16, 2025 at 07:37:35PM +0200, Alex Rønne Petersen wrote:
> >> > On Fri, May 30, 2025, at 00:42, Alex Rønne Petersen wrote:
> >> > > The default setting for -ffp-contract is implementation-defined, so make
> >> > > -ffp-contract=off explicit. This matters on clang in particular where
> >> > > contraction is on by default even in standard C mode. Because of this, clang
> >> > > will turn these expressions into llvm.fmuladd.* intrinsic calls in the
> >> > > generated LLVM IR. This means we're completely at the mercy of the backend in
> >> > > regards to whether those intrinsics get lowered to an fma() call or simply
> >> > > fmul + fadd instructions. Similarly, optimization passes are allowed to perform
> >> > > transformations on those intrinsic calls that fmul + fadd would not permit.
> >> > >
> >> > > Older gcc versions had a similar issue and required -mno-fused-madd, hence set
> >> > > this as well.
> >> > >
> >> > > With zig cc -target arm-linux-musleabi, we've seen a case where clang turned
> >> > > a * b + c into an fma() library call in musl's fma() implementation itself,
> >> > > resulting in infinite recursion. This patch also fixes that.
> >> > > ---
> >> > > configure | 9 +++++++++
> >> > > 1 file changed, 9 insertions(+)
> >> > >
> >> > > diff --git a/configure b/configure
> >> > > index bc9fbe48..aa890101 100755
> >> > > --- a/configure
> >> > > +++ b/configure
> >> > > @@ -355,6 +355,15 @@ tryflag CFLAGS_C99FSE -fexcess-precision=standard \
> >> > > || { test "$ARCH" = i386 && tryflag CFLAGS_C99FSE -ffloat-store ; }
> >> > > tryflag CFLAGS_C99FSE -frounding-math
> >> > >
> >> > > +#
> >> > > +# Explicitly disable floating point contraction because the default
> >> > > +# setting is implementation-defined, and clang is known to have it
> >> > > +# on by default even in standard C mode. The same was true in older
> >> > > +# gcc versions, hence -mno-fused-add as well.
> >> > > +#
> >> > > +tryflag CFLAGS_C99FSE -mno-fused-madd
> >> > > +tryflag CFLAGS_C99FSE -ffp-contract=off
> >> > > +
> >> > > #
> >> > > # Semantically we want to insist that our sources follow the
> >> > > # C rules for type-based aliasing, but most if not all real-world
> >> > > --
> >> > > 2.48.1
> >> >
> >> > Friendly ping.
> >>
> >> Thanks. I'm looking back at this now and I thought we were using
> >> #pragma STDC FP_CONTRACT OFF and compilers just weren't honoring it,
> >> but it seems we're not. Is this not supported by gcc and/or clang?
> >> Because this is what we really should be doing, with the CFLAGS just
> >> as a fallback in case a broken compiler doesn't honor it.
> >
> > To answer my own question, it looks like gcc is ignoring the pragma
> > but clang (at least 20.1.0, tested on godbolt) honors it.
> >
> > In any case I think we should add the pragma for correctness and the
> > command line option as a safety for broken compilers.
> >
> > Rich
>
> Using the pragma makes sense; I wasn't actually aware that it
> exists. That said, I don't think I'm qualified to say where it
> should be applied (besides fma).
FWIW gcc does default to -ffp-contract=off in standards compliant mode
(-std=c?? instead of gnu??) which we use, so it's already doing the
right thing. But I still want to add both this patch and the pragmas,
since the standard has no guarantee it won't do contraction. The only
reason gcc has contraction off in standards mode is that they don't
implement a version of contraction that's compliant. The standard only
allows contraction under certain conditions, but AIUI gcc has already
performed transformations that are lossy with respect to those
conditions at the time contraction would be applied, so it can't
evaluate if it's allowed to perform contraction.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
