From patchwork Fri Aug 16 19:27:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 1148398 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-104527-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="wB6yw/bW"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 469Cy122N6z9sBF for ; Sat, 17 Aug 2019 05:27:20 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; q=dns; s=default; b=W8KR2jSdNe6hruNWBb5dU5CnwKD7a HBL95jmMB/sKRUvZtcZUO4jNohv7YGPDmCHEXi4pS/oDnhIBsv4MG+EaDqGZmvtU 5nxvQGBTzCpLGcd8XAwuUuMp3OriI6lzc/w/ct7nx8ZHZHz4FBPy74Ln4eaV+kzo Q8qBqNhFrMFF40= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; s=default; bh=D9qnh6Us+nEzeOMKTtEj/yQHwII=; b=wB6 yw/bWB4bkfNEERZW+apxnMtk6xJykV8bXb1hdyzNWmnS/SXy1ow/n7TKXyWs+JP6 MMDtLM+6kTA7rJLvx0GDD1nIVAsKRneyZHgnoFSNvXu9QabhNa69ZBRXPwNqeJgH MZlokwNvBJaUQCdS3LYcLdEpO2dkf8OSfi2CNPbc= Received: (qmail 111145 invoked by alias); 16 Aug 2019 19:27:14 -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 111135 invoked by uid 89); 16 Aug 2019 19:27:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:2560 X-HELO: esa2.mentor.iphmx.com IronPort-SDR: nDXDjb3KCn3ac+zB+jEnR4nEfPuSJO/OEj5YSHcl5f0Qvod9g66NXecJ3L0Uj0xp8u27Oooqcz 9sF/Cg8jA05KUG0mf0h8YDHbSQ877T+dU1wC9QYQHwPuRgavO0t1V8HRvV05+BOaUqtAJsPOrS F5mlPbcvLTIhQKGaW/0yJ5btTEwq8dBX8aeh1UmbEQE8tTtAwI5GtvgYoR5DXdhtCztfntGEPB 21+iDRczixtWrKMsRM+dyaIdg6N3K8PY+G8Cn6Bbf30p86h7dy5q5aQM7JWMGxdgnpacM+EpUQ nxw= IronPort-SDR: /c/dn0/oLr36gC+9ufbT1Vj3VzXzVofmu0hW5q8vknE6f0sVvy4CNexUfeadt+41JJRhArL33P SfzRd4T65A6orFEN+t3XiLz8Q8apTgxNqVDZX2oQKjwDteLOAA2xhmhrhqt+1vXdp/uPQytlRP JVIEUxVketj/IWotRQ0QdUQgLScO0YcTzRK5t3O5jeGZCDBHpj1TJ4wkgPmowvrp6NV4tQHnud 9Det4/WrM0j5OkpppjFGZxYSGA8AcYicGYF4NwLZ5ntKHlX/TLRj1pzfGSz8OCiZXgpchT5bdL UXY= Date: Fri, 16 Aug 2019 19:27:06 +0000 From: Joseph Myers To: Subject: Correct TEST_COMPAT conditions in totalorder compat tests [committed] Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 I noticed that the totalorder compat tests mixed TEST_COMPAT conditions using COMPAT_VER (computed as the first symbol version for the symbol being tested) and those with a hardcoded GLIBC_2_25. COMPAT_VER is logically correct here, so this patch changes the tests to use it. GLIBC_2_25 is harmless at present (even for _FloatN / _FloatNx functions added in later glibc versions). However, if in future we support _Float16 functions in glibc for any existing configuration, the test using GLIBC_2_25 would get things wrong (wrongly think that there are compat versions of totalorderf16 and totalordermagf16 to test). (The actual definitions of the compat / versioned symbols for the totalorder functions make no attempt to deal with the possibility of libm function support for a new floating-point format, already supported for other architectures in glibc, being added in some glibc configuration in future, for which the only vaguely plausible case would be if some architecture gets _Float128 support it previously lacked; this is much like functions added after glibc 2.4 not generally attempting to deal with compat support for long double changing away from having the same format as double.) Tested for x86_64, and with build-many-glibcs.py. Committed. 2019-08-16 Joseph Myers * math/libm-test-compat_totalorder.inc (do_test) [TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31)]: Change condition to [TEST_COMPAT (libm, COMPAT_VER, GLIBC_2_31)]. * math/libm-test-compat_totalordermag.inc (do_test) [TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31)]: Likewise. diff --git a/math/libm-test-compat_totalorder.inc b/math/libm-test-compat_totalorder.inc index 7ad87342fd..313e9475c9 100644 --- a/math/libm-test-compat_totalorder.inc +++ b/math/libm-test-compat_totalorder.inc @@ -44,7 +44,7 @@ compat_totalorder_test (void) static void do_test (void) { -#if TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31) +#if TEST_COMPAT (libm, COMPAT_VER, GLIBC_2_31) compat_totalorder_test (); #endif } diff --git a/math/libm-test-compat_totalordermag.inc b/math/libm-test-compat_totalordermag.inc index 1f82946fbf..5cbe8797a3 100644 --- a/math/libm-test-compat_totalordermag.inc +++ b/math/libm-test-compat_totalordermag.inc @@ -44,7 +44,7 @@ compat_totalordermag_test (void) static void do_test (void) { -#if TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31) +#if TEST_COMPAT (libm, COMPAT_VER, GLIBC_2_31) compat_totalordermag_test (); #endif }