[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZop=riNRxaF+JD-BPU0HrNdq-ztZdr5=z7XuxtLXD4QzjQ@mail.gmail.com>
Date: Thu, 25 Jul 2024 08:26:37 -0400
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Subject: Re: #pragma STDC FENV_ACCESS ON
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`.
> > > You need
> > > nondefault CFLAGS instead. And even if it did help, it would just be
> > > facilitating wrong/nonportable code. The reason nobody's using it is
> >
> > (it's used in musl's fmal() :-) )
>
> The "it" was putting a hidden blanket "#pragma STDC FENV_ACCESS ON" in
> the system fenv.h. We do not do that. We use it correctly at the
> source level of files that needs it.
ah, right. and, yes, it looks like that's the only affected file in musl.
oddly i failed to convince the freebsd-numerics folks of that
(https://lists.freebsd.org/archives/freebsd-numerics/2024-July/subject.html).
> > > that the compilers ignore it (and IIRC at least at one point even
> > > spammed warnings to that effect).
> >
> > clang will still complain if you use it for arm32 ... but requires it
> > for x86-64.
>
> Lovely...
>
> > > 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.)
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).
btw, see also https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2746r0.pdf
where the guy down the hall is suggesting that rather than copy
FENV_ACCESS into C++, C++ should just say "the <fenv.h> rounding mode
stuff is too broken --- let's replace it with _types_ that carry a
rounding mode".
> 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.
