Message ID | 20240403121150.1018799-1-adhemerval.zanella@linaro.org |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E221038449C6 for <patchwork@sourceware.org>; Wed, 3 Apr 2024 12:12:30 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 1C19B3847718 for <libc-alpha@sourceware.org>; Wed, 3 Apr 2024 12:11:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C19B3847718 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1C19B3847718 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::433 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712146318; cv=none; b=Q8sZIqorzWs0j23Qu4uF9IhM7Jq/+LVEjDaAtZmIWE6QyLzmQKM8jiesmWd3tLlPk7P1mhdP0hxem9+93jsWVZwOP6Wg4bMVOLanG1fJPFQ3/XKWOb+9TtWjxhpvI/phVNOweDogcCvEfvR2QIcPSXHlBVOI/4uEKLxg42ctcSM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712146318; c=relaxed/simple; bh=b3hUEQAvExL2y/47ID5bko1aSYqaEc00e9utLd2MNPg=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=ZcVBrCnTnHT1gdDakZITbGbHcGH8SpCZar3ZaNq2d3RD0AffNQzVijEOFufatuVqun3YgZqCy/kEbs+fMwCzlus/to5ivdE4mgfJSG00FhyCsETpg4gu/H2PaRuytgS45IYppoPcWOmCFsRFiy4ALwiks+fUThwsX8ndUxFRwro= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6eae2b57ff2so5079825b3a.2 for <libc-alpha@sourceware.org>; Wed, 03 Apr 2024 05:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712146314; x=1712751114; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=bZZsVJyZ8rcueGpPJOh07bNWGLaN+1GsrYV3y6UMLus=; b=fj8yq73bSksX5RYGTMlPrPAenjPolh2rWLJRTXFrTjdGUjQ6Gb0P0nMVwuzns5mW3d WdwwyULCEODhPtMNE8qW4uVg6QyZuOslX56oaRssPb1LoHaG9d9+/MbJapkHqtp2E0M/ x2PMKw2bVNr0CjnuVyRco1Nulch0zYBUfzCvDQrw3byR8aVCsqKBxeWrf1opPYmXbzia D8b/3z/as6kbL7huR1Miwpu4/j3uA+8EcgpPmtEk0wDZvovlOPZq0k5TW1VO2AYvPdJv NnYAaHmMahSZKHXUCmZNmmZy+xGXcuHUfjBsIG5hdbeVwIOa0wTWgcVsZ26BccAEG78c w5MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712146314; x=1712751114; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bZZsVJyZ8rcueGpPJOh07bNWGLaN+1GsrYV3y6UMLus=; b=eVlwvHaAFHotmSjGOZaZqVcBaXqwau5E5gMEksltHdZyNcVhzkZSOfe3JfqQoEljCh I1HfTQKmngfoGPyGqS/M2l6zCWEIUrEdrmo5QMTSId7DEM+anls9BYLrdPioeyyLNsrK ain+bqg642647je4+Mume3gN1U3dkKZdc3nA5vXyNF22mgX8HuzgE/BnVSKq9kWoQcpP K1CrpDIo6N471LY6gI5M3NRew9kTP+MqVpM1uM+G0Hf63l+oPwCgF3wXT1Fv23ZqCtXB vfNgHAY12WlNQQmy1jzGw03777hryFgqOu6CsrA1U3+2rM5BV6uva5XIbLRTTbg4qL+E mHyw== X-Gm-Message-State: AOJu0Yzn4QtdIkN1/2h6uszClNxeEAO3LqSUfvNLmUTEouCJr2UeyXAb AJQvZiGAVaG9o9I1kyUC9BgTDUgIAldYdnuvAoum6LDbZgpsZN48hZKeERjphPUhMDfZ4MssFrk P X-Google-Smtp-Source: AGHT+IGHfK0buToIjXSoe3htZyQwIeyNaEfZ/hIL2Y9kY5M9gvwgp8W1Ln/p0+Iy6wwUH8sR8FiLeA== X-Received: by 2002:a05:6a20:d705:b0:1a5:7979:3349 with SMTP id iz5-20020a056a20d70500b001a579793349mr18168311pzb.6.1712146314604; Wed, 03 Apr 2024 05:11:54 -0700 (PDT) Received: from mandiga.. ([2804:1b3:a7c3:b18e:12db:8f9c:da5:36ce]) by smtp.gmail.com with ESMTPSA id q6-20020a17090a938600b0029ffcf1df72sm13574141pjo.38.2024.04.03.05.11.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 05:11:54 -0700 (PDT) From: Adhemerval Zanella <adhemerval.zanella@linaro.org> To: libc-alpha@sourceware.org Cc: "H . J . Lu" <hjl.tools@gmail.com> Subject: [PATCH v2 00/10] Improve rounding to interger function for C23 Date: Wed, 3 Apr 2024 09:11:40 -0300 Message-Id: <20240403121150.1018799-1-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Improve rounding to interger function for C23
|
|
Message
Adhemerval Zanella Netto
April 3, 2024, 12:11 p.m. UTC
As indicated by GCC documentation [1], ISO C23 does not allow that C bindings ceil, floor, round, and trunc (in all floating point formats) to raise inexact exceptions (different than ISO C99/C11 where this is allowed). A recent MIPS patch to used some arch-specific instructions raised this issue [1] and it was not caught because there was no proper testing. By adding the missing tests, some implementations do indeed raise inexact exceptions. The generic implementation all uses integer operation, so they are not subject to this issue. The powerpc (for power4 and lower) and the riscv avoid the inexact exception by disabling/enabling exceptions. The x86 uses some arch-specific implementation for long double and on i386 (due to the use of x87 instruction). Instead of adding newer symbols depending on the required standard version, the patchset adapts the faulty ones to avoid raising the inexact exception. The x86 version already saves/restore the floating point status, so I think it is unlikely the patch would yield much performance difference (I did not do any performance analysis on whether a generic implementation would yield better performance). I checked on powerpc, powerpc64, aarch64, armhf, x86, and did some regression checks on riscv. [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fno-fp-int-builtin-inexact [2] https://sourceware.org/pipermail/libc-alpha/2023-December/153528.html Changes from v1: * Updated Copyright years. Adhemerval Zanella (10): math: Add test to check if ceil raise inexact floating-point exception math: Add test to check if floor raise inexact floating-point exception math: Add test to check if trunc raise inexact floating-point exception math: Add test to check if round raise inexact floating-point exception x86: Do not raise inexact exception on ceill x86: Do not raise inexact exception on floorl x86: Do not raise inexact exception on truncl x86: Do not raise inexact exception on floor/floorf i386: Do not raise inexact exception on ceil/ceilf i386: Do not raise inexact exception on trunc/truncf math/Makefile | 17 ++++ math/test-ceil-except-2.c | 67 +++++++++++++++ math/test-ceil-except.c | 85 +++++++++++++++++++ math/test-floor-except-2.c | 67 +++++++++++++++ math/test-floor-except.c | 85 +++++++++++++++++++ math/test-round-except-2.c | 67 +++++++++++++++ math/test-round-except.c | 85 +++++++++++++++++++ math/test-trunc-except-2.c | 67 +++++++++++++++ math/test-trunc-except.c | 85 +++++++++++++++++++ sysdeps/i386/fpu/s_ceil.S | 34 -------- sysdeps/i386/fpu/s_ceil.c | 38 +++++++++ sysdeps/i386/fpu/s_ceilf.S | 34 -------- sysdeps/i386/fpu/s_ceilf.c | 38 +++++++++ sysdeps/i386/fpu/s_ceill.S | 39 --------- sysdeps/i386/fpu/s_floor.S | 34 -------- sysdeps/i386/fpu/s_floor.c | 38 +++++++++ sysdeps/i386/fpu/s_floorf.S | 34 -------- sysdeps/i386/fpu/s_floorf.c | 38 +++++++++ sysdeps/i386/fpu/s_floorl.S | 39 --------- sysdeps/i386/fpu/{s_trunc.S => s_trunc.c} | 37 ++++---- sysdeps/i386/fpu/{s_truncf.S => s_truncf.c} | 37 ++++---- .../fpu/s_truncl.S => x86/fpu/s_ceill.c} | 38 +++++---- sysdeps/x86/fpu/s_floorl.c | 38 +++++++++ .../fpu/s_truncl.S => x86/fpu/s_truncl.c} | 40 +++++---- sysdeps/x86_64/fpu/s_ceill.S | 34 -------- sysdeps/x86_64/fpu/s_floorl.S | 33 ------- 26 files changed, 892 insertions(+), 356 deletions(-) create mode 100644 math/test-ceil-except-2.c create mode 100644 math/test-ceil-except.c create mode 100644 math/test-floor-except-2.c create mode 100644 math/test-floor-except.c create mode 100644 math/test-round-except-2.c create mode 100644 math/test-round-except.c create mode 100644 math/test-trunc-except-2.c create mode 100644 math/test-trunc-except.c delete mode 100644 sysdeps/i386/fpu/s_ceil.S create mode 100644 sysdeps/i386/fpu/s_ceil.c delete mode 100644 sysdeps/i386/fpu/s_ceilf.S create mode 100644 sysdeps/i386/fpu/s_ceilf.c delete mode 100644 sysdeps/i386/fpu/s_ceill.S delete mode 100644 sysdeps/i386/fpu/s_floor.S create mode 100644 sysdeps/i386/fpu/s_floor.c delete mode 100644 sysdeps/i386/fpu/s_floorf.S create mode 100644 sysdeps/i386/fpu/s_floorf.c delete mode 100644 sysdeps/i386/fpu/s_floorl.S rename sysdeps/i386/fpu/{s_trunc.S => s_trunc.c} (61%) rename sysdeps/i386/fpu/{s_truncf.S => s_truncf.c} (61%) rename sysdeps/{x86_64/fpu/s_truncl.S => x86/fpu/s_ceill.c} (57%) create mode 100644 sysdeps/x86/fpu/s_floorl.c rename sysdeps/{i386/fpu/s_truncl.S => x86/fpu/s_truncl.c} (61%) delete mode 100644 sysdeps/x86_64/fpu/s_ceill.S delete mode 100644 sysdeps/x86_64/fpu/s_floorl.S
Comments
On Wed, 3 Apr 2024, Adhemerval Zanella wrote: > As indicated by GCC documentation [1], ISO C23 does not allow that C > bindings ceil, floor, round, and trunc (in all floating point formats) > to raise inexact exceptions (different than ISO C99/C11 where this is > allowed). > > A recent MIPS patch to used some arch-specific instructions raised this > issue [1] and it was not caught because there was no proper testing. By > adding the missing tests, some implementations do indeed raise inexact > exceptions. There is testing that, in the terminology used by IEEE 754, the operations do not raise the exception flag (the result of default exception handling when the exception is signaled). This is done through NO_INEXACT_EXCEPTION in libm-test-*.inc. What is not tested is specifically quality of implementation when exception traps are enabled (a GNU extension outside the scope of the C standard). I think that as a user-visible fix, there should be a bug filed in Bugzilla for this issue (that can then be marked FIXED so it goes in the automatically generated list of bugs fixed in the next release).
On 03/04/24 12:03, Joseph Myers wrote: > On Wed, 3 Apr 2024, Adhemerval Zanella wrote: > >> As indicated by GCC documentation [1], ISO C23 does not allow that C >> bindings ceil, floor, round, and trunc (in all floating point formats) >> to raise inexact exceptions (different than ISO C99/C11 where this is >> allowed). >> >> A recent MIPS patch to used some arch-specific instructions raised this >> issue [1] and it was not caught because there was no proper testing. By >> adding the missing tests, some implementations do indeed raise inexact >> exceptions. > > There is testing that, in the terminology used by IEEE 754, the operations > do not raise the exception flag (the result of default exception handling > when the exception is signaled). This is done through > NO_INEXACT_EXCEPTION in libm-test-*.inc. > > What is not tested is specifically quality of implementation when > exception traps are enabled (a GNU extension outside the scope of the C > standard). Ack, I will add that we are now testing for exception traps. > > I think that as a user-visible fix, there should be a bug filed in > Bugzilla for this issue (that can then be marked FIXED so it goes in the > automatically generated list of bugs fixed in the next release). > Alright, I open bug for the x86 issues.
Dear Adhemerval, since nobody seems to have noticed, please fix the subject of this thread: interger -> integer. Paul