From owner-freebsd-numerics@freebsd.org Mon Jul 23 18:28:22 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 490181051EA3 for ; Mon, 23 Jul 2018 18:28:22 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2C76891CD for ; Mon, 23 Jul 2018 18:28:21 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lj1-x22e.google.com with SMTP id f8-v6so1383244ljk.1 for ; Mon, 23 Jul 2018 11:28:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/2sahZxSYRuYKaouUizQWpDgNP6HBp46p7GA4YXwTXg=; b=G5DkvUsZFhAiSjPppILK3AtralL52EN0mtxzhpE38SOGGQ+9mCYa9BoPyktERuMKWD KVKBcUKniZj1FZkIORUkLaiB9ac3nMVu/0yK3lG9DR5gg99fFTdnVqzBnCXlp05JFLtu MJ5JuKyL+F4jMAAK8K2x5noAN1KJkLfGWw650jV9KaRxSM6TcvBd6dJ8T/NFCUOf2tXh KfTK14E0GT/CNhN4u4EDKsKcU/0G9zvtaCKYzWJtIuworB/jF49+li+9HrTW7CBXbGoz Ij1+pqjyHL9nn2VXz6QSBreVugdHPMuaKX1R+ljnjJ/7lYBtjmPrB+bSdw/6DjMGUiqw Ox/Q== X-Gm-Message-State: AOUpUlGGbvUOYYTUJ4ky9yI2ff8D/gLGRZNRXesUL/kAhekX7KVoMhVD XARvWfNo1FQ8JD2xk3NrWptLtvqzbNr0UPdbb3yVGhH8Ck32Ug== X-Google-Smtp-Source: AAOMgpfuz9CEv6tN0BikqPUheGLcRfNECsWka31r/cbyoeiaKvXUP6HCP90hMWf0wCXT4Ms7sj5Ve68bz3bsYDsWOKY= X-Received: by 2002:a2e:2bd7:: with SMTP id r84-v6mr10113178ljr.40.1532370499830; Mon, 23 Jul 2018 11:28:19 -0700 (PDT) MIME-Version: 1.0 From: enh Date: Mon, 23 Jul 2018 11:28:08 -0700 Message-ID: Subject: fmod nan_mix usage To: freebsd-numerics@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:28:22 -0000 the recent change from return (x*y)/(x*y); to return nan_mix(x, y)/nan_mix(x, y); in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in one of the VM tests. bionic/tests/math_test.cpp:(784) Failure in test math_h_force_long_double.fmod Value of: isnan(fmod(3.0, 0.0)) Actual: false Expected: true math_h_force_long_double.fmod exited with exitcode 1. [ FAILED ] math_h_force_long_double.fmodf (13 ms) bionic/tests/math_test.cpp:(798) Failure in test math_h_force_long_double.fmodf Value of: isnanf(fmodf(3.0f, 0.0f)) Actual: false Expected: true math_h_force_long_double.fmodf exited with exitcode 1. [ FAILED ] math_h_force_long_double.fmodl (12 ms) bionic/tests/math_test.cpp:(812) Failure in test math_h_force_long_double.fmodl Value of: isnanl(fmodl(3.0L, 0.0L)) Actual: false Expected: true it looks like e_remainder.c might have the same issue, but Android's tests didn't catch that :-( i'll improve the tests... From owner-freebsd-numerics@freebsd.org Mon Jul 23 19:34:26 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B182610533A1 for ; Mon, 23 Jul 2018 19:34:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D60D8B677 for ; Mon, 23 Jul 2018 19:34:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w6NJYI2f066463 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 23 Jul 2018 12:34:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w6NJYIAb066462 for freebsd-numerics@freebsd.org; Mon, 23 Jul 2018 12:34:18 -0700 (PDT) (envelope-from sgk) Date: Mon, 23 Jul 2018 12:34:18 -0700 From: Steve Kargl To: enh via freebsd-numerics Subject: Re: fmod nan_mix usage Message-ID: <20180723193418.GA66380@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:34:26 -0000 On Mon, Jul 23, 2018 at 11:28:08AM -0700, enh via freebsd-numerics wrote: > the recent change from > > return (x*y)/(x*y); > > to > > return nan_mix(x, y)/nan_mix(x, y); > > in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in > one of the VM tests. > > bionic/tests/math_test.cpp:(784) Failure in test > math_h_force_long_double.fmod > Value of: isnan(fmod(3.0, 0.0)) > Actual: false > Expected: true Can you share the code for the relevant tests? This simple program gives the expected results on amd64. #include #include int main(void) { printf("%e %d\n", fmodf(3.f, 0.f), isnan(fmodf(3.f, 0.f))); printf("%le %d\n", fmod(3.0, 0.0), isnan(fmod(3.0, 0.0))); printf("%Le %d\n", fmodl(3.L, 0.L), isnan(fmodl(3.L, 0.L))); return 0; } % cc -o z -O a.c -lm && ./z nan 1 nan 1 nan 1 -- Steve From owner-freebsd-numerics@freebsd.org Mon Jul 23 19:54:47 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8421E1053961 for ; Mon, 23 Jul 2018 19:54:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 026BA8C14C for ; Mon, 23 Jul 2018 19:54:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 0C7613C91AC; Tue, 24 Jul 2018 05:54:38 +1000 (AEST) Date: Tue, 24 Jul 2018 05:54:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: enh cc: freebsd-numerics@freebsd.org Subject: Re: fmod nan_mix usage In-Reply-To: Message-ID: <20180724050141.Q2280@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=I9sVfJog c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=3UsIx-7XcedfqCigM80A:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:54:47 -0000 On Mon, 23 Jul 2018, enh via freebsd-numerics wrote: > the recent change from > > return (x*y)/(x*y); > > to > > return nan_mix(x, y)/nan_mix(x, y); > > in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in > one of the VM tests. This is a bug in my change. nan_mix(x, y) does essentially x+y, but here essentially x*y is needed so that y = 0 gives 0 unless x is NaN. In the example, adding gives 3 instead of 0, so the final result is 1 instead of 0.0/0.0 = NaN. The log message mentions avoiding this problem in s_ccosh[fl].c and s_sinh[fl].c. This list was supposed have all special cases. Unfortunately, this seems to prevent use of a single macro. I will try using a 2 macros with 1 using sums and the other products. The non-broken cases converted sums to sums. > bionic/tests/math_test.cpp:(784) Failure in test > math_h_force_long_double.fmod > Value of: isnan(fmod(3.0, 0.0)) > Actual: false > Expected: true > math_h_force_long_double.fmod exited with exitcode 1. > [ FAILED ] math_h_force_long_double.fmodf (13 ms) > bionic/tests/math_test.cpp:(798) Failure in test > math_h_force_long_double.fmodf > Value of: isnanf(fmodf(3.0f, 0.0f)) > Actual: false > Expected: true > math_h_force_long_double.fmodf exited with exitcode 1. > [ FAILED ] math_h_force_long_double.fmodl (12 ms) > bionic/tests/math_test.cpp:(812) Failure in test > math_h_force_long_double.fmodl > Value of: isnanl(fmodl(3.0L, 0.0L)) > Actual: false > Expected: true Do you have a lot of special tests like this? I mostly use generic tests that don't assert any particular result, but compare the results in different precisions. I apparently changed all precisions to be consistently wrong at the same time. > it looks like e_remainder.c might have the same issue, but Android's tests > didn't catch that :-( i'll improve the tests... Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* and ccosh*, and it was. The only other complicated case seems to be hypot[fl](). This subtracts instead of adds, since it wants to convert Inf-Inf to NaN. Bruce From owner-freebsd-numerics@freebsd.org Mon Jul 23 21:30:50 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 170751055469 for ; Mon, 23 Jul 2018 21:30:50 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D20D8F8D3 for ; Mon, 23 Jul 2018 21:30:49 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lj1-x22c.google.com with SMTP id f8-v6so1793721ljk.1 for ; Mon, 23 Jul 2018 14:30:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gmCcFvCxUYx0PnwnChdBWsP2oDlYFZjROxlEg9n6sfU=; b=a1KBxZSTmEl5oGjFqYqjCWs1v/JzF0jP2y09YQtffpyYxQTid7d6A+y0M0KccXhyGo EJ9BQAZwe4+/dWLmiQ1uA7/SAyvgWAU8V0B3VWK8cYTsr2jzwXPYRBGa/mxWXgEHqPIo JPZpy/99INMk14E9HMOgmXoH/jipR3brtFbpK11O/O7dl3SqqEDKZgFmG6LXdklIUiCz WuahwVaiD5CHLvOktUWzC5H09scPHX+Uzyy2+Y14PmKq8I9cMZpxAVLMZfS8z+MfQqdt unFuEooQY4WW0S3MRLbaQYyDa2gZ6Tp3QFwUTm7FsfxIBZ+bwekos7vWh0Zt6XQ5IdAN e6sQ== X-Gm-Message-State: AOUpUlHrWlTdMUwS6R7BeGWoB4C691rRDjyx3U+WAobqQ96hLp/Q9QlD 2ADIDU4d/+JOSWaBGvy+6ztxk2FwUMTB1oMzA3Vmh5sw7cYxaQ== X-Google-Smtp-Source: AAOMgpfnzLgNwIGJddRUNy/sjH0vIHc8BZe952bJhOT+rovWiF3YptYKm5/ilkb0NaBBWVo3AGOo5uraw9Rffri7qfg= X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr9615909ljc.148.1532381447582; Mon, 23 Jul 2018 14:30:47 -0700 (PDT) MIME-Version: 1.0 References: <20180724050141.Q2280@besplex.bde.org> In-Reply-To: <20180724050141.Q2280@besplex.bde.org> From: enh Date: Mon, 23 Jul 2018 14:30:35 -0700 Message-ID: Subject: Re: fmod nan_mix usage To: brde@optusnet.com.au Cc: freebsd-numerics@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 21:30:50 -0000 On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans wrote: > On Mon, 23 Jul 2018, enh via freebsd-numerics wrote: > > > the recent change from > > > > return (x*y)/(x*y); > > > > to > > > > return nan_mix(x, y)/nan_mix(x, y); > > > > in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in > > one of the VM tests. > > This is a bug in my change. > > nan_mix(x, y) does essentially x+y, but here essentially x*y is needed so > that y = 0 gives 0 unless x is NaN. In the example, adding gives 3 instead > of 0, so the final result is 1 instead of 0.0/0.0 = NaN. > > The log message mentions avoiding this problem in s_ccosh[fl].c and > s_sinh[fl].c. This list was supposed have all special cases. > > Unfortunately, this seems to prevent use of a single macro. I will try > using a 2 macros with 1 using sums and the other products. The non-broken > cases converted sums to sums. > > > bionic/tests/math_test.cpp:(784) Failure in test > > math_h_force_long_double.fmod > > Value of: isnan(fmod(3.0, 0.0)) > > Actual: false > > Expected: true > > math_h_force_long_double.fmod exited with exitcode 1. > > [ FAILED ] math_h_force_long_double.fmodf (13 ms) > > bionic/tests/math_test.cpp:(798) Failure in test > > math_h_force_long_double.fmodf > > Value of: isnanf(fmodf(3.0f, 0.0f)) > > Actual: false > > Expected: true > > math_h_force_long_double.fmodf exited with exitcode 1. > > [ FAILED ] math_h_force_long_double.fmodl (12 ms) > > bionic/tests/math_test.cpp:(812) Failure in test > > math_h_force_long_double.fmodl > > Value of: isnanl(fmodl(3.0L, 0.0L)) > > Actual: false > > Expected: true > > Do you have a lot of special tests like this? I mostly use generic tests > that don't assert any particular result, but compare the results in > different precisions. I apparently changed all precisions to be > consistently wrong at the same time. > bionic doesn't have as many as it should, though i do add them any time we catch a regression. all our tests are in https://android.googlesource.com/platform/bionic/+/master/tests/ with complex_test.cpp and math_test.cpp being the interesting ones. (complex_test.cpp is laughably perfunctory right now, but sadly *did* catch bugs where historically the makefiles were broken and we weren't shipping all the functions for all the architectures.) i do try to ensure that we use the BSD rather than APL2 license for the tests, though apparently i failed in both these cases. i'll fix the headers if that helps. i don't think the contributed Android tests in math_data/ are very high quality. i have no reason to believe they're not just random numbers (and glibc fails several of them, and i don't know who's right in those cases). the external/arm-optimized-routines project (corresponding to https://github.com/ARM-software/optimized-routines) has much better tests (for those functions they support) and clearly distinguish between directed and random testing: https://github.com/ARM-software/optimized-routines/tree/master/test/testcases > > it looks like e_remainder.c might have the same issue, but Android's > tests > > didn't catch that :-( i'll improve the tests... > > Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* > and ccosh*, and it was. > yeah, i caught remquo after i hit send (and have just uploading a CL with the missing tests). i'm glad to hear that ctanh* actually works because i'd failed to break it :-) i'll commit those extra tests too anyway. (strictly, the netbsd ctanhl we use is broken for the NaN+0i case, returning NaN+NaNi rather than NaN+0i, but that's not your fault, other than that i'll switch to the freebsd ld128 ctanhl as soon as it exists :-) ) > The only other complicated case seems to be hypot[fl](). This subtracts > instead of adds, since it wants to convert Inf-Inf to NaN. > hypot seems okay from my testing. am i missing another test? > Bruce > From owner-freebsd-numerics@freebsd.org Mon Jul 23 21:41:22 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B2DB105576E for ; Mon, 23 Jul 2018 21:41:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id A61ED8FEFB for ; Mon, 23 Jul 2018 21:41:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id D6AC53C9B76; Tue, 24 Jul 2018 07:41:18 +1000 (AEST) Date: Tue, 24 Jul 2018 07:41:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: enh via freebsd-numerics Subject: Re: fmod nan_mix usage In-Reply-To: <20180723193418.GA66380@troutmask.apl.washington.edu> Message-ID: <20180724071036.O868@besplex.bde.org> References: <20180723193418.GA66380@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=EseilWUA c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=F2OS3LCdxiRRRJEjMt0A:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 21:41:22 -0000 On Mon, 23 Jul 2018, Steve Kargl wrote: > On Mon, Jul 23, 2018 at 11:28:08AM -0700, enh via freebsd-numerics wrote: >> the recent change from >> >> return (x*y)/(x*y); >> >> to >> >> return nan_mix(x, y)/nan_mix(x, y); >> >> in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in >> one of the VM tests. >> >> bionic/tests/math_test.cpp:(784) Failure in test >> math_h_force_long_double.fmod >> Value of: isnan(fmod(3.0, 0.0)) >> Actual: false >> Expected: true > > Can you share the code for the relevant tests? > This simple program gives the expected results > on amd64. > > #include > #include > > int > main(void) > { > printf("%e %d\n", fmodf(3.f, 0.f), isnan(fmodf(3.f, 0.f))); > printf("%le %d\n", fmod(3.0, 0.0), isnan(fmod(3.0, 0.0))); > printf("%Le %d\n", fmodl(3.L, 0.L), isnan(fmodl(3.L, 0.L))); > return 0; > } > > % cc -o z -O a.c -lm && ./z > nan 1 > nan 1 > nan 1 clang normally evaluates this at compile, so it doesn't test the libary. This is arguably a bug in clang, since it doesn't set the exception flags. #pragma FENV_ACCESS should control this, but it is hard to use and rarely works. The test data needs to be non-literal and perhaps even volatile to prevent the compiler evaluating it at compile time. Bruce From owner-freebsd-numerics@freebsd.org Mon Jul 23 21:59:31 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 587771055BD4 for ; Mon, 23 Jul 2018 21:59:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D8DC570781 for ; Mon, 23 Jul 2018 21:59:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w6NLxSKA098486 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jul 2018 14:59:28 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w6NLxSWP098485; Mon, 23 Jul 2018 14:59:28 -0700 (PDT) (envelope-from sgk) Date: Mon, 23 Jul 2018 14:59:28 -0700 From: Steve Kargl To: Bruce Evans Cc: enh via freebsd-numerics Subject: Re: fmod nan_mix usage Message-ID: <20180723215928.GA98418@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180723193418.GA66380@troutmask.apl.washington.edu> <20180724071036.O868@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724071036.O868@besplex.bde.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 21:59:31 -0000 On Tue, Jul 24, 2018 at 07:41:17AM +1000, Bruce Evans wrote: > On Mon, 23 Jul 2018, Steve Kargl wrote: > > > > Can you share the code for the relevant tests? > > This simple program gives the expected results > > on amd64. > > > > #include > > #include > > > > int > > main(void) > > { > > printf("%e %d\n", fmodf(3.f, 0.f), isnan(fmodf(3.f, 0.f))); > > printf("%le %d\n", fmod(3.0, 0.0), isnan(fmod(3.0, 0.0))); > > printf("%Le %d\n", fmodl(3.L, 0.L), isnan(fmodl(3.L, 0.L))); > > return 0; > > } > > > > % cc -o z -O a.c -lm && ./z > > nan 1 > > nan 1 > > nan 1 > > clang normally evaluates this at compile, so it doesn't test the libary. > This is arguably a bug in clang, since it doesn't set the exception flags. > #pragma FENV_ACCESS should control this, but it is hard to use and rarely > works. > > The test data needs to be non-literal and perhaps even volatile to prevent > the compiler evaluating it at compile time. > Whoops. I should know better! I have -fno-builtins hardcoded in my development trees and completely forgot about constant folding. -- Steve From owner-freebsd-numerics@freebsd.org Tue Jul 24 06:19:25 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C64B1041928 for ; Tue, 24 Jul 2018 06:19:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id E183F81695 for ; Tue, 24 Jul 2018 06:19:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 84B7D1A0B9B; Tue, 24 Jul 2018 16:19:12 +1000 (AEST) Date: Tue, 24 Jul 2018 16:19:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: enh via freebsd-numerics Subject: Re: fmod nan_mix usage In-Reply-To: <20180723215928.GA98418@troutmask.apl.washington.edu> Message-ID: <20180724155513.A819@besplex.bde.org> References: <20180723193418.GA66380@troutmask.apl.washington.edu> <20180724071036.O868@besplex.bde.org> <20180723215928.GA98418@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=NlcgX5Ohdpa1gglEm_sA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 06:19:25 -0000 On Mon, 23 Jul 2018, Steve Kargl wrote: > On Tue, Jul 24, 2018 at 07:41:17AM +1000, Bruce Evans wrote: >> ... >> clang normally evaluates this at compile, so it doesn't test the libary. >> This is arguably a bug in clang, since it doesn't set the exception flags. >> #pragma FENV_ACCESS should control this, but it is hard to use and rarely >> works. ["This" is fmod*(3, 0).] >> The test data needs to be non-literal and perhaps even volatile to prevent >> the compiler evaluating it at compile time. > > Whoops. I should know better! I have -fno-builtins hardcoded > in my development trees and completely forgot about constant > folding. I just realised that testing should be done with all combinations of builtin flags, or at least global -fbuiltin and -fnon-builtin. clang might inline all fmod calls. clang recently started inlining all fmin and fmax calls, and the result is different than the library -- the library is careful to order -0.0 before +0.0, but clang doesn't distingish between these values so it produces one depending on the order of the args and other details. C99 footnote 192 explicitly says that the sloppy comparison is allowed, so this is only a quality of implementation bug. Both gcc and clang have always inlined fabs calls and have almost always inlined sqrt calls. For efficiency testing, I rename functions by copying their file and editing the file, and rebuild them with the CFLAGS being tested, so that the main part of the function is independent of the library including the CFLAGS that it was built with, and builtins. This only renames fabs and sqrt when testing these functions. The function call overhead for small functions like fabs is about 10 cycles on modern x86, except for long double precision it is about 30 cycles. For accuracy testing, it is the function that will normally be used that should usually be tested. This is the builtin if there is one, or the library function. However, the builtins should be turned off sometimes, to get an idea of what the non-builtin function will do with other compilers/ arches where it is not a builtin. Similarly for optimized MD versions. My efficiency tests usually turn off the x86-optimized versions. Non-i386 arches don't have so many optimized MD versions, so just testing the library functions on them finds most differences that don't show up for the optimized MD versions. Bruce From owner-freebsd-numerics@freebsd.org Tue Jul 24 18:22:14 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7F291052B6A for ; Tue, 24 Jul 2018 18:22:14 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BF297A6FC for ; Tue, 24 Jul 2018 18:22:14 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lf1-x134.google.com with SMTP id u14-v6so3658172lfu.0 for ; Tue, 24 Jul 2018 11:22:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zlps8yLSvPK8Yy35WSIpJ1DgRc0KCvY3XJCEcEiiRaY=; b=h2RBoGtyPq5s2twiacdUjOrmhMb24vMk8tR5UcEAcmQ3BMJ903kUvKdfSlRThy9qln 3bD0StVYZPS7bhj3QC2tPeznxlvGS8P3jN7Pn7Tb71wBqQpGcW6xBfOI516sFfJJVTzz YxoIXFQXksZFaj2X7kTLjIdHCjHI3ru8XaFmdJIDeM5uOPAJ1d4QR8INt6RoyvkNHlRM +49EIiiTJ392+6aVYc3minR2wX+2WPatFMj4kT8sgFymxWQle1SZgXBKEWvtqWfF1gR1 nMcZr2lq4DMl18BxpIhK3tuUUFO4RH0CxD7IUE3J3oglOnlS+rF+mZO7IiVeVcgsC4Y3 8GuQ== X-Gm-Message-State: AOUpUlFhgWYqJM5Ew8gDGyd5Hk+OpIEw9U5b1/cHA7JqH7kdbZreK/jE 6okBslTp+LIJli//xzIA2e9OQ0SHV3TcgC0mVBLXmA== X-Google-Smtp-Source: AAOMgpdlENWWzUVNyUWyXDp4poygXuJIUgtbUrunsmDVxzrl7FBZdPc4zYzh/aJJhTEZ6JxdBLUjCjwfQDPnAmn4qYY= X-Received: by 2002:a19:1366:: with SMTP id j99-v6mr10652599lfi.21.1532456532549; Tue, 24 Jul 2018 11:22:12 -0700 (PDT) MIME-Version: 1.0 References: <20180724050141.Q2280@besplex.bde.org> In-Reply-To: From: enh Date: Tue, 24 Jul 2018 11:22:00 -0700 Message-ID: Subject: Re: fmod nan_mix usage To: brde@optusnet.com.au Cc: freebsd-numerics@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:22:15 -0000 the fix you committed passes all my tests. thanks! On Mon, Jul 23, 2018 at 2:30 PM enh wrote: > > > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans wrote: > >> On Mon, 23 Jul 2018, enh via freebsd-numerics wrote: >> >> > the recent change from >> > >> > return (x*y)/(x*y); >> > >> > to >> > >> > return nan_mix(x, y)/nan_mix(x, y); >> > >> > in e_fmod.c broke some of our unit tests. for example, fmod(3.f, 0.f) in >> > one of the VM tests. >> >> This is a bug in my change. >> >> nan_mix(x, y) does essentially x+y, but here essentially x*y is needed so >> that y = 0 gives 0 unless x is NaN. In the example, adding gives 3 >> instead >> of 0, so the final result is 1 instead of 0.0/0.0 = NaN. >> >> The log message mentions avoiding this problem in s_ccosh[fl].c and >> s_sinh[fl].c. This list was supposed have all special cases. >> >> Unfortunately, this seems to prevent use of a single macro. I will try >> using a 2 macros with 1 using sums and the other products. The non-broken >> cases converted sums to sums. >> >> > bionic/tests/math_test.cpp:(784) Failure in test >> > math_h_force_long_double.fmod >> > Value of: isnan(fmod(3.0, 0.0)) >> > Actual: false >> > Expected: true >> > math_h_force_long_double.fmod exited with exitcode 1. >> > [ FAILED ] math_h_force_long_double.fmodf (13 ms) >> > bionic/tests/math_test.cpp:(798) Failure in test >> > math_h_force_long_double.fmodf >> > Value of: isnanf(fmodf(3.0f, 0.0f)) >> > Actual: false >> > Expected: true >> > math_h_force_long_double.fmodf exited with exitcode 1. >> > [ FAILED ] math_h_force_long_double.fmodl (12 ms) >> > bionic/tests/math_test.cpp:(812) Failure in test >> > math_h_force_long_double.fmodl >> > Value of: isnanl(fmodl(3.0L, 0.0L)) >> > Actual: false >> > Expected: true >> >> Do you have a lot of special tests like this? I mostly use generic tests >> that don't assert any particular result, but compare the results in >> different precisions. I apparently changed all precisions to be >> consistently wrong at the same time. >> > > bionic doesn't have as many as it should, though i do add them any time we > catch a regression. all our tests are in > https://android.googlesource.com/platform/bionic/+/master/tests/ with > complex_test.cpp and math_test.cpp being the interesting ones. > (complex_test.cpp is laughably perfunctory right now, but sadly *did* catch > bugs where historically the makefiles were broken and we weren't shipping > all the functions for all the architectures.) > > i do try to ensure that we use the BSD rather than APL2 license for the > tests, though apparently i failed in both these cases. i'll fix the headers > if that helps. > > i don't think the contributed Android tests in math_data/ are very high > quality. i have no reason to believe they're not just random numbers (and > glibc fails several of them, and i don't know who's right in those cases). > > the external/arm-optimized-routines project (corresponding to > https://github.com/ARM-software/optimized-routines) has much better tests > (for those functions they support) and clearly distinguish between directed > and random testing: > https://github.com/ARM-software/optimized-routines/tree/master/test/testcases > > >> > it looks like e_remainder.c might have the same issue, but Android's >> tests >> > didn't catch that :-( i'll improve the tests... >> >> Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* >> and ccosh*, and it was. >> > > yeah, i caught remquo after i hit send (and have just uploading a CL with > the missing tests). i'm glad to hear that ctanh* actually works because i'd > failed to break it :-) i'll commit those extra tests too anyway. > > (strictly, the netbsd ctanhl we use is broken for the NaN+0i case, > returning NaN+NaNi rather than NaN+0i, but that's not your fault, other > than that i'll switch to the freebsd ld128 ctanhl as soon as it exists :-) ) > > >> The only other complicated case seems to be hypot[fl](). This subtracts >> instead of adds, since it wants to convert Inf-Inf to NaN. >> > > hypot seems okay from my testing. am i missing another test? > > >> Bruce >> > From owner-freebsd-numerics@freebsd.org Wed Jul 25 07:35:06 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25CA81041CCF for ; Wed, 25 Jul 2018 07:35:06 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 95278736BD for ; Wed, 25 Jul 2018 07:35:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 54661428975; Wed, 25 Jul 2018 17:34:54 +1000 (AEST) Date: Wed, 25 Jul 2018 17:34:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: enh cc: freebsd-numerics@freebsd.org Subject: Re: fmod nan_mix usage In-Reply-To: Message-ID: <20180725170218.M835@besplex.bde.org> References: <20180724050141.Q2280@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=EseilWUA c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=Oh2cFVv5AAAA:8 a=Wpfb0w___zvaJdmtPHIA:9 a=CjuIK1q_8ugA:10 a=7KeoIwV6GZqOttXkcoxL:22 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 07:35:06 -0000 On Mon, 23 Jul 2018, enh wrote: > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans wrote: > ... > bionic doesn't have as many as it should, though i do add them any time we > catch a regression. all our tests are in > https://android.googlesource.com/platform/bionic/+/master/tests/ with > complex_test.cpp and math_test.cpp being the interesting ones. > (complex_test.cpp is laughably perfunctory right now, but sadly *did* catch > bugs where historically the makefiles were broken and we weren't shipping > all the functions for all the architectures.) Are most of your systems arm? I think libm doesn't get much testing on arm in FreeBSD (I have never even run cc on an arm system), so it especially useful to have tests for it on other systems. This also partly explains why my recent tests didn't see the bug -- x86 has fmod, remainder and remquo in asm or builtins so the C versions are not normally used. Maybe arm should have a bit more in asm or builtins. > ... >>> it looks like e_remainder.c might have the same issue, but Android's >> tests >>> didn't catch that :-( i'll improve the tests... >> >> Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* >> and ccosh*, and it was. > > yeah, i caught remquo after i hit send (and have just uploading a CL with > the missing tests). i'm glad to hear that ctanh* actually works because i'd > failed to break it :-) i'll commit those extra tests too anyway. ctanh* turned out to not need multiplicative NaN mixing. It is both more complicated and simpler than ccosh* and csinh*, since it has more complicated expressions so needs more special cases for exceptional args, but then the individual cases are simpler. >... >> The only other complicated case seems to be hypot[fl](). This subtracts >> instead of adds, since it wants to convert Inf-Inf to NaN. > > hypot seems okay from my testing. am i missing another test? It passes my tests too, but uses a complicated method to pass. I first noticed difference related to precisions with it, and fixed them less systematically than with nan_mix*. I think it only uses subtractive mixing because that worked to preserve the arg order in SSE because SSE doesn't have reverse subtraction. That is too special. Bruce From owner-freebsd-numerics@freebsd.org Wed Jul 25 16:07:18 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8710E104E901 for ; Wed, 25 Jul 2018 16:07:18 +0000 (UTC) (envelope-from enh@google.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6AEA83D05 for ; Wed, 25 Jul 2018 16:07:17 +0000 (UTC) (envelope-from enh@google.com) Received: by mail-lj1-x22b.google.com with SMTP id f1-v6so7151601ljc.9 for ; Wed, 25 Jul 2018 09:07:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j82Epxdswl2iXNoDrlbQArXtf0aKbiFLwa8HmDnoa0U=; b=geTBJX5XNyj+VHufxSmZDYwmBbHzYoSfWWNHAXiw72LUtF2sys2aSuryMojtpuEd6v O3sL/myU0nidXHgLQhcjjogbcDP1e/cJcnFgPgilR+Lb5fHQdEI05y6fHVbfDW12eOuF N5zw81cA1vb/ctW++gpyUBoGPhwmiBVIFlUl91uuc3vIeDnw2pWKmlP95NWBVadUFyJc tbvwZc0HsTjbi+0vfmmR+z9r+lxT1Q6uy6mZT3UmWrNszTVaF6W9HzmWxUGdY/vzzTDn RNe29yjRu02QgjOu+8UGSkgpVBK8ZWbpCQMMHNimP1LA3YlhyC2gHJdRa/L32/CQeebP B+iA== X-Gm-Message-State: AOUpUlGZxEPQONqL9eolVNz0B+E+Vop8O1sItaaYtAevoWovMv+9mXQS yWFdBvZaSxlf22KLT0nP2F338lg9v8XUW/plsN+uPQ== X-Google-Smtp-Source: AAOMgpc6CYKyosdIAphadOYWeQot1LNXFLXH5uzU1+g3UH6shdhAJIY3p/evtlijHO/dWg6v0T6FCfFtrg6XwsJjWJY= X-Received: by 2002:a2e:9599:: with SMTP id w25-v6mr7150444ljh.6.1532534836027; Wed, 25 Jul 2018 09:07:16 -0700 (PDT) MIME-Version: 1.0 References: <20180724050141.Q2280@besplex.bde.org> <20180725170218.M835@besplex.bde.org> In-Reply-To: <20180725170218.M835@besplex.bde.org> From: enh Date: Wed, 25 Jul 2018 09:07:04 -0700 Message-ID: Subject: Re: fmod nan_mix usage To: brde@optusnet.com.au Cc: freebsd-numerics@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:07:18 -0000 On Wed, Jul 25, 2018 at 12:34 AM Bruce Evans wrote: > On Mon, 23 Jul 2018, enh wrote: > > > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans > wrote: > > ... > > bionic doesn't have as many as it should, though i do add them any time > we > > catch a regression. all our tests are in > > https://android.googlesource.com/platform/bionic/+/master/tests/ with > > complex_test.cpp and math_test.cpp being the interesting ones. > > (complex_test.cpp is laughably perfunctory right now, but sadly *did* > catch > > bugs where historically the makefiles were broken and we weren't shipping > > all the functions for all the architectures.) > > Are most of your systems arm? to a first-order approximation, pretty much all Android devices run arm code (even the x86-based ones, via binary translation!). about half also run arm64. x86/x86-64 is mostly used for the emulator (because that's what everyone's desktop/laptop is, and virtualization gets you a ridiculously fast emulator). > I think libm doesn't get much testing on arm > in FreeBSD (I have never even run cc on an arm system), so it especially > useful to have tests for it on other systems. This also partly explains > why my recent tests didn't see the bug -- x86 has fmod, remainder and > remquo in asm or builtins so the C versions are not normally used. Maybe > arm should have a bit more in asm or builtins. > in bionic we've actually been trying to encourage them to fix clang to use intrinsics, and then -- where clang can produce equivalent code -- we replace our .S files with something like `T f(T x) { return __builtin_f(x); }`. that way, sure, we get good code in libm, but far more importantly callers get to skip libm entirely and just get a single instruction inlined. (bionic's tests are then full of the usual tricks to ensure that we actually call the libm functions.) > > ... > > >>> it looks like e_remainder.c might have the same issue, but Android's > >> tests > >>> didn't catch that :-( i'll improve the tests... > >> > >> Indeed. Also remquo* and ctanh* :-(. ctanh* should be more like csinh* > >> and ccosh*, and it was. > > > > yeah, i caught remquo after i hit send (and have just uploading a CL with > > the missing tests). i'm glad to hear that ctanh* actually works because > i'd > > failed to break it :-) i'll commit those extra tests too anyway. > > ctanh* turned out to not need multiplicative NaN mixing. It is both more > complicated and simpler than ccosh* and csinh*, since it has more > complicated > expressions so needs more special cases for exceptional args, but then the > individual cases are simpler. > > >... > >> The only other complicated case seems to be hypot[fl](). This subtracts > >> instead of adds, since it wants to convert Inf-Inf to NaN. > > > > hypot seems okay from my testing. am i missing another test? > > It passes my tests too, but uses a complicated method to pass. I first > noticed difference related to precisions with it, and fixed them less > systematically than with nan_mix*. I think it only uses subtractive > mixing because that worked to preserve the arg order in SSE because > SSE doesn't have reverse subtraction. That is too special. > > Bruce > From owner-freebsd-numerics@freebsd.org Fri Jul 27 17:40:39 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC9C21051C12 for ; Fri, 27 Jul 2018 17:40:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 335857F5D1 for ; Fri, 27 Jul 2018 17:40:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EC9CD1051C0D; Fri, 27 Jul 2018 17:40:38 +0000 (UTC) Delivered-To: numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B28E81051C0C for ; Fri, 27 Jul 2018 17:40:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 530C57F5CC for ; Fri, 27 Jul 2018 17:40:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A19381EDBE for ; Fri, 27 Jul 2018 17:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6RHebe0048425 for ; Fri, 27 Jul 2018 17:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6RHebqM048424 for numerics@FreeBSD.org; Fri, 27 Jul 2018 17:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: numerics@FreeBSD.org Subject: [Bug 229876] [libm] Fix powl, cpow, cpowf, and cpowl imports from OpenBSD Date: Fri, 27 Jul 2018 17:40:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable10+ mfc-stable11+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:40:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229876 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Fri Jul 27 17:39:39 UTC 2018 New revision: 336767 URL: https://svnweb.freebsd.org/changeset/base/336767 Log: MFC r327400 (by eadler): cacos(3): correct spelling of 'I' In some cases we had 'i' instead of 'I'. PR: 195517 Submitted by: stephen MFC r329259 (by eadler): msun: signed overflow in atan2 As a component of atan2(y, x), the case of x =3D=3D 1.0 is farmed out to atan(y). The current implementation of this comparison is vulnerable to signed integer underflow (that is, undefined behavior), and it's performed in a somewhat more complicated way than it need be. Change it to not be quite so cute, rather directly comparing the high/low bits of x to the specific IEEE-754 bit pattern that encodes 1.0. Note that while there are three different e_atan* files in the relevant directory, only this one needs fixing. e_atan2f.c already compares against the full bit pattern encoding 1.0f, while e_atan2l.cuses bitwise-ands/ors/nots and so doesn't require a change. Closes #130 Submitted by: Jeff Walden (@jswalden github PR #130) Reviewed by: bde MFC r334721 (by cem): clog.3, complex.3: Fix typos and igor style issues PR: 228783 Reported by: Karsten MFC r336299 (by mmacy): msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd This corresponds to the latest status (hasn't changed in 9+ years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, cpowl (the complex power functions for float complex, double complex, and long double complex) which are required for C99 compliance and were missing from FreeBSD. Also required for some numerical codes using complex numbered Hamiltonians. Thanks to jhb for tracking down the issue with making weak_reference compile on powerpc. When asked to review, bde said "I don't like it" - but provided no actionable feedback or superior implementations. Discussed with: jhb Submitted by: jmd Differential Revision: https://reviews.freebsd.org/D15919 MFC r336563: Recommit r336497: Fix powl, cpow, cpowf, and cpowl imports from OpenBSD This is a follow-up to r336299. * lib/msun/Makefile: . Remove polevll.c * lib/msun/ld80/e_powl.c: . Copy contents of polevll.c to here. This is the only consumer of these functions. Make functions 'static inline'. . Make reducl a 'static inline' function. * lib/msun/man/exp.3: . Remove BUGS section that no longer applies. * lib/msun/src/math_private.h: . Remove prototypes of __p1evll() and __polevll() * lib/msun/src/s_cpow.c: * lib/msun/src/s_cpowf.c: * lib/msun/src/s_cpowl.c . Include math_private.h. . Use the CMPLX macro from either C99 or math_private.h (depends on compiler support) instead of the problematic use of complex I. Submitted by: Steve Kargl PR: 229876 Changes: _U stable/11/ stable/11/include/complex.h stable/11/lib/msun/Makefile stable/11/lib/msun/Symbol.map stable/11/lib/msun/ld128/e_powl.c stable/11/lib/msun/ld80/e_powl.c stable/11/lib/msun/man/cacos.3 stable/11/lib/msun/man/clog.3 stable/11/lib/msun/man/complex.3 stable/11/lib/msun/man/cpow.3 stable/11/lib/msun/man/exp.3 stable/11/lib/msun/src/e_atan2.c stable/11/lib/msun/src/e_pow.c stable/11/lib/msun/src/imprecise.c stable/11/lib/msun/src/math_private.h stable/11/lib/msun/src/s_cpow.c stable/11/lib/msun/src/s_cpowf.c stable/11/lib/msun/src/s_cpowl.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-numerics@freebsd.org Fri Jul 27 17:47:50 2018 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30BAB1051E9C for ; Fri, 27 Jul 2018 17:47:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C186A7FA75 for ; Fri, 27 Jul 2018 17:47:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 86C831051E98; Fri, 27 Jul 2018 17:47:49 +0000 (UTC) Delivered-To: numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75A5C1051E97 for ; Fri, 27 Jul 2018 17:47:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13F7E7FA73 for ; Fri, 27 Jul 2018 17:47:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5BE5B1EE1A for ; Fri, 27 Jul 2018 17:47:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6RHlmfk063804 for ; Fri, 27 Jul 2018 17:47:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6RHlmrs063803 for numerics@FreeBSD.org; Fri, 27 Jul 2018 17:47:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: numerics@FreeBSD.org Subject: [Bug 229876] [libm] Fix powl, cpow, cpowf, and cpowl imports from OpenBSD Date: Fri, 27 Jul 2018 17:47:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable10+ mfc-stable11+ X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:47:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229876 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --=20 You are receiving this mail because: You are on the CC list for the bug.=