[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240725152523.GM10433@brightrain.aerifal.cx>
Date: Thu, 25 Jul 2024 11:25:23 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: #pragma STDC FENV_ACCESS ON
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.
> > > > 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.
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.
