From patchwork Wed Jul 27 19:56:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Senkevich X-Patchwork-Id: 14055 Received: (qmail 78591 invoked by alias); 27 Jul 2016 19:57:02 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 78581 invoked by uid 89); 27 Jul 2016 19:57:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=Myers X-HELO: mail-vk0-f68.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oKwypKMONpCVQHKw4rsHEKzNFN256DY3LaUygT0RpfI=; b=UgB6eatewb0YvuaD/JnF8TZyC79WD/dFSuXdH23YD6ve/65FwMLVg99htlaHB2R6hG PbE2wtNEAXyEvjFTCdzVmtTS8yfYcrEi4T88FUfqw1BYTMUrolrv7EcqCuAi/n9PB6mb n5pORpt62018j5CooT3oRiifdL3IFVIFJmlRwfCdrfClRi6fUy8pJHz85Jb+XVJ/FIYT Y65PXKesTsrrPd/Te7u3Fqk3/obUZrOPqqDdaVMuzOjSBzJnN/cvxXTHA0m6D8aeSrSw IYOeOAC+2oGeDHsuuke1TRH5LCcGR68qmoOm4nU7PISPgIVymsHIHM5BiJfI04ariw3h Rp/w== X-Gm-Message-State: AEkoouvdbVlzbGQxgXheZMDLSE7VZsBC8eSOeWiPNhAlw8aRYlDwTE6ZInMzAGfZejArvmsks/FzZbr2ZOgKlw== X-Received: by 10.31.115.140 with SMTP id o134mr13984373vkc.0.1469649409824; Wed, 27 Jul 2016 12:56:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Andrew Senkevich Date: Wed, 27 Jul 2016 22:56:20 +0300 Message-ID: Subject: Re: [PATCH x86_64][BZ #20033] Use calls to finite scalar versions in vector log, pow, exp. To: Joseph Myers Cc: libc-alpha 2016-07-25 23:19 GMT+03:00 Joseph Myers : > On Mon, 25 Jul 2016, Andrew Senkevich wrote: > >> > No, such architecture conditionals on individual tests are not >> > appropriate. Maybe you need a NO_TEST_VECTOR handled like NO_TEST_INLINE >> > in enable_test. >> >> Is patch below Ok for trunk? > > No, I said handled like NO_TEST_INLINE. Exactly like NO_TEST_INLINE. No > architecture conditionals, no #if, just an "if" conditional exactly > corresponding to how NO_TEST_INLINE and NON_FINITE are handled (the > NON_FINITE if is actually better to follow since it follows the glibc > convention of avoiding implicit boolean conversion). Do you mean the following change for math/libm-test.inc? TEST_ff_f (pow, 1.1L, plus_infty, plus_infty, ERRNO_UNCHANGED|NO_TEST_INLINE), TEST_ff_f (pow, plus_infty, plus_infty, plus_infty, ERRNO_UNCHANGED|NO_TEST_INLINE), --- WBR, Andrew diff --git a/math/libm-test.inc b/math/libm-test.inc index 4ac7a0c..117057c 100644 --- a/math/libm-test.inc +++ b/math/libm-test.inc @@ -179,6 +179,7 @@ #define IGNORE_RESULT 0x20000 #define NON_FINITE 0x40000 #define TEST_SNAN 0x80000 +#define NO_TEST_MATHVEC 0x100000 #define __CONCATX(a,b) __CONCAT(a,b) @@ -1056,6 +1057,9 @@ enable_test (int exceptions) return 0; if (!SNAN_TESTS (FLOAT) && (exceptions & TEST_SNAN) != 0) return 0; + if (TEST_MATHVEC && (exceptions & NO_TEST_MATHVEC) != 0) + return 0; + return 1; } @@ -10631,10 +10635,10 @@ nexttoward_test (void) static const struct test_ff_f_data pow_test_data[] = { - TEST_ff_f (pow, qnan_value, 0, 1, ERRNO_UNCHANGED), - TEST_ff_f (pow, -qnan_value, 0, 1, ERRNO_UNCHANGED), - TEST_ff_f (pow, qnan_value, minus_zero, 1, ERRNO_UNCHANGED), - TEST_ff_f (pow, -qnan_value, minus_zero, 1, ERRNO_UNCHANGED), + TEST_ff_f (pow, qnan_value, 0, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC), + TEST_ff_f (pow, -qnan_value, 0, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC), + TEST_ff_f (pow, qnan_value, minus_zero, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC), + TEST_ff_f (pow, -qnan_value, minus_zero, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC),