From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15008 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] fmax(), fmaxf(), fmaxl(), fmin(), fminf(), fminl() simplified Date: Wed, 11 Dec 2019 08:25:54 -0500 Message-ID: <20191211132554.GN1666@brightrain.aerifal.cx> References: <557979287957451E9255CCBC4CD7CBE5@H270> <20191211104955.GN23985@port70.net> <5BF8FB2FE1AA418393E6091F7F8AFC14@H270> <20191211131659.GQ23985@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="219469"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stefan Kanthak To: musl@lists.openwall.com Original-X-From: musl-return-15024-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 11 14:26:12 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1if20K-000uzq-3e for gllmg-musl@m.gmane.org; Wed, 11 Dec 2019 14:26:12 +0100 Original-Received: (qmail 9250 invoked by uid 550); 11 Dec 2019 13:26:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9224 invoked from network); 11 Dec 2019 13:26:06 -0000 Content-Disposition: inline In-Reply-To: <20191211131659.GQ23985@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:15008 Archived-At: On Wed, Dec 11, 2019 at 02:16:59PM +0100, Szabolcs Nagy wrote: > * 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) : ... Yes, I think having this conditioned on GNUC would be acceptable, provided the builtin is supported in all versions of GNUC going back conceivably far. > > > you should run any such change through libc-test > > > git://repo.or.cz/libc-test 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) I think it's "ok" to submit patches without having run tests, with the caveat that it's going to impact how willing folks are to review them, and if so how quickly it gets done. If submitting patches you haven't tested, text explaining the reasoning for why you think they're correct (e.g. "nan behavior is still correct because line N produces a nan and the function is allowed to raise invalid under this condition") would help a lot since thought processes like that are hard to reverse-engineer. Rich