Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Dec 2019 14:16:59 +0100
From: Szabolcs Nagy <>
Cc: Stefan Kanthak <>
Subject: Re: [PATCH] fmax(), fmaxf(), fmaxl(), fmin(), fminf(),
 fminl() simplified

* Stefan Kanthak <> [2019-12-11 13:33:44 +0100]:
> "Szabolcs Nagy" <> wrote:
> >* Stefan Kanthak <> [2019-12-11 10:55:29 +0100]:
> > these two are not equivalent for snan input, but we dont care
> > about snan, nor the compiler by default, so the compiler can
> > optimize one to the other (although musl uses explicit int
> > arithmetics instead of __builtin_isnan so it's a bit harder).
> The latter behaviour was my reason to use (x != x) here: I attempt
> to replace as many function calls as possible with "normal" code,
> and also try to avoid transfers to/from FPU/SSE registers to/from
> integer registers if that does not result in faster/shorter code.

why not just change the definition of isnan then?

#if __GNUC__ > xxx
#define isnan(x) sizeof(x)==sizeof(float) ? __builtin_isnanf(x) : ...

> > you should run any such change through libc-test
> > git:// and look for regressions.
> I already told Rich that I neither use an OS nor a compiler/assembler
> where musl or libc-test can be built.

it does not matter where you use musl, if you want
to submit patches you have to test on supported
targets (since it's not realistic to test on all
configurations, at least one relevant configuration
is enough)

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.