[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJgzZophsHjRKy-SiDz6TT2jf-esuVGWZWWEp0mm7_-tAVwoYw@mail.gmail.com>
Date: Thu, 25 Jul 2024 12:13:16 -0400
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Subject: Re: #pragma STDC FENV_ACCESS ON
On Thu, Jul 25, 2024 at 11:25 AM Rich Felker <dalias@...c.org> wrote:
>
> On Thu, Jul 25, 2024 at 08:26:37AM -0400, enh wrote:
> > On Wed, Jul 24, 2024 at 8:23 PM Rich Felker <dalias@...c.org> wrote:
> > >
> > > On Wed, Jul 24, 2024 at 05:48:16PM -0400, enh wrote:
> > > > On Wed, Jul 24, 2024 at 2:31 PM Rich Felker <dalias@...c.org> wrote:
> > > > >
> > > > > On Thu, Jul 18, 2024 at 01:28:02PM -0400, enh wrote:
> > > > > > has anyone else considered adding `#pragma STDC FENV_ACCESS ON` to
> > > > > > <fenv.h>? expecting callers to realize they [might] have to do this
> > > > > > [depending on their compiler and architecture] if they want to safely
> > > > > > use most of the functions in <fenv.h> doesn't seem to be working out
> > > > > > too well, even for libm authors...
> > > > > >
> > > > > > all the choices seem bad.
> > > > >
> > > > > That wouldn't even help because the compilers don't honor it.
> > > >
> > > > well, it's worse than that --- some need it, some don't. and even for
> > > > a given compiler, it depends on the specific target architecture. (and
> > > > i think MS' compilers have a different non-standard pragma instead.)
> > >
> > > If the compiler doesn't honor it but has CFLAGS you can use that give
> > > the equivalent semantics, then you can just use those and let the
> > > pragma get ignore. That's what we do in musl -- we use the pragma
> > > correctly, but since we don't expect the compiler will honor it, we
> > > also use CFLAGS that should make it so the effects of the pragma are
> > > always be in effect.
> >
> > where? i don't see the relevant flags for clang in your Makefile, just
> > `-ffreestanding -nostdinc`.
>
> configure:356:
>
> tryflag CFLAGS_C99FSE -frounding-math
>
> If clang needs something else we're missing, let me know.
ah, i should have grepped rather than assuming i knew where to look.
yeah, that's the main one. -fno-math-errno can be important if you
_want_ the compiler to use a builtin.
> > > > > Get the compilers fixed, teach them
> > > > > to issue warnings when fenv functions are called without the pragma in
> > > > > effect, and everything else will fix itself.
> > > >
> > > > lol, sure, but back in the real world where the compiler writers don't
> > > > care about their users, and the standards committees don't care
> > > > whether the language as standardized is actually usable or not...
> > > >
> > > > i think the strongest "meh, whatever, it's also not the libc owners'
> > > > problem --- just leave users to deal with it" argument is probably
> > > > that hardly anyone who doesn't own a libm actually cares about
> > > > <fenv.h>. Android's arm32 <fenv.h> was completely broken (because
> > > > someone had copy & pasted the BSD _mips_ inline assembler) for years,
> > > > and afaik no user noticed --- i noticed when i was doing the arm64
> > > > port and wrote the first test.
> > >
> > > It's not that it's "not our problem". It's that we're not in a
> > > position of being able to fix it.
> >
> > define "fix"... we can at least make it "no worse than it used to be
> > before compiler writers started using FENV_ACCESS as an excuse to
> > misbehave". (we could even curate a list of which architectures need
> > it.)
>
> No, you do not "curate a list of which architectures need it". The C
> language is very clear: you *always* need it if you want to use fenv.
> If not, the compiler is free to optimize in ways that break nondefault
> fenv.
>
> > back in the cons column, though, it looks like there are bugs where
> > this makes the compiler too conservative, and it won't use (say)
> > inline instructions for libm rounding functions even though they're
> > safe (because the instructions explicitly specify a rounding mode
> > rather than relying on the dynamic rounding mode). this, of course,
> > being only some for some architectures with clang (i haven't even
> > tried gcc).
>
> That is not "too conservative". It's behaving exactly as intended. If
> you want to use fenv, those optimizations are invalid, and the
> compiler has to refrain from making them.
no, something like ceil() or round() has a clearly defined behavior,
and -- since we're talking about the case where the instruction used
has an explicit rounding mode -- the optimization preserves that
behavior. even if you're claiming that ceil() has undefined behavior
in the presence of <fenv.h>, it's _still_ valid to do the optimization
that gives you the what-it-says-on-the-tin behavior.
> 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.
