From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 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 dcvr.yhbt.net (Postfix) with ESMTPS id CA90E1F4C1 for ; Tue, 29 Oct 2019 15:42:54 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=iJupXr6J0s+yzzGd 69KclN8BLwt0Z/4/U5V8qLxVuk50RPGwX6Pl12hu4cLGTQA4wU+ciHkT8imbiyyl GhuumvxjLcKH2W4sv84RPTnYVBHbU1WLH9fqCDHpi7ykqH2obG9jIsmMZsIzVrFB qWYYY+4g+huBFYcE7w0Pr5NyU0I= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=yXDEwQBLcOU/3XR38xq8d3 1FYfE=; b=kmOSDDk8bA/E+wSSznSjTPT5IUWJNiyGZxDNeKogkEG5F2PgFcSXkS 5qa/t6Ye5SE36InakQ0IadsquxDJY0nIeTH++a4i7iDcNlTZBVL2486/MZa8GT8G iqIiH5NSbaFkWpOC96g0Tgizg84Rveq4aPaOOJ4smU6qZhtxoN+Jg= Received: (qmail 47030 invoked by alias); 29 Oct 2019 15:42:51 -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 Received: (qmail 47013 invoked by uid 89); 29 Oct 2019 15:42:50 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH v2 01/30] ldbl-128ibm-compat: Add regular character printing functions To: "Gabriel F. T. Gomes" , libc-alpha@sourceware.org References: <20191025153410.15405-1-gabriel@inconstante.net.br> <20191025153410.15405-2-gabriel@inconstante.net.br> From: Paul E Murphy Message-ID: <013053c7-d6ce-6e4f-4dfd-799ffe1951f3@linux.ibm.com> Date: Tue, 29 Oct 2019 10:42:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20191025153410.15405-2-gabriel@inconstante.net.br> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/25/19 10:33 AM, Gabriel F. T. Gomes wrote: > From: "Gabriel F. T. Gomes" > > No changes since v1. > > -- 8< -- > The 'mode' argument to __vfprintf_internal allows the selection of the > long double format for all long double arguments requested by the format > string. Currently, there are two possibilities: long double with the > same format as double or long double as something else. The 'something > else' format varies between architectures, and on powerpc64le, it means > IBM Extended Precision format. > > In preparation for the third option of long double format on > powerpc64le, this patch uses the new mode mask, > PRINTF_LDBL_USES_FLOAT128, which tells __vfprintf_internal to save the > floating-point values into variables of type __float128 and adjusts the > parameters to __printf_fp and __printf_fphex as if it was a call from > strfromf128. > > Many files from the stdio-common, wcsmbs, argp, misc, and libio > directories will have IEEE binary128 counterparts. Setting the correct > compiler options to these files (original and counterparts) would > produce a large amount of repetitive Makefile rules. To avoid this > repetition, this patch adds a Makefile routine that iterates over the > files adding or removing the appropriate flags. > > Tested for powerpc64le. > --- > elf/tst-addr1.c | 7 +- > sysdeps/ieee754/ldbl-128ibm-compat/Makefile | 47 ++++- > sysdeps/ieee754/ldbl-128ibm-compat/Versions | 15 ++ > .../ldbl-128ibm-compat/ieee128-asprintf.c | 35 ++++ > .../ldbl-128ibm-compat/ieee128-dprintf.c | 34 ++++ > .../ldbl-128ibm-compat/ieee128-fprintf.c | 34 ++++ > .../ldbl-128ibm-compat/ieee128-printf.c | 35 ++++ > .../ldbl-128ibm-compat/ieee128-snprintf.c | 35 ++++ > .../ldbl-128ibm-compat/ieee128-sprintf.c | 35 ++++ > .../ldbl-128ibm-compat/ieee128-vasprintf.c | 27 +++ > .../ldbl-128ibm-compat/ieee128-vdprintf.c | 26 +++ > .../ldbl-128ibm-compat/ieee128-vfprintf.c | 26 +++ > .../ldbl-128ibm-compat/ieee128-vprintf.c | 27 +++ > .../ldbl-128ibm-compat/ieee128-vsnprintf.c | 28 +++ > .../ldbl-128ibm-compat/ieee128-vsprintf.c | 27 +++ > .../ldbl-128ibm-compat/test-printf-ibm128.c | 1 + > .../ldbl-128ibm-compat/test-printf-ieee128.c | 1 + > .../test-printf-ldbl-compat.c | 171 ++++++++++++++++++ > .../powerpc64/le/ldbl-128ibm-compat-abi.h | 8 + > 19 files changed, 617 insertions(+), 2 deletions(-) > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-asprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-dprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-fprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-snprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-sprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vasprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vdprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vfprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vsnprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/ieee128-vsprintf.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ibm128.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ieee128.c > create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ldbl-compat.c > create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/le/ldbl-128ibm-compat-abi.h > > diff --git a/elf/tst-addr1.c b/elf/tst-addr1.c > index 68ff74aabd..ee81acda5b 100644 > --- a/elf/tst-addr1.c > +++ b/elf/tst-addr1.c > @@ -19,7 +19,12 @@ do_test (void) > rather than in the binary. printf and _IO_printf > are aliased and which one comes first in the > hash table is up to the linker. */ > - && strcmp (i.dli_sname, "_IO_printf") != 0); > + && strcmp (i.dli_sname, "_IO_printf") != 0 > + /* On architectures where long double with IEEE binary128 > + format is available as a third option (initially, true > + for powerpc64le), printf may be redirected to > + __printfieee128. */ > + && strcmp (i.dli_sname, "__printfieee128") != 0); Should there be a guard against this test for architectures which will never support this symbol? > } > > #include > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/Makefile b/sysdeps/ieee754/ldbl-128ibm-compat/Makefile > index 412beb5b5c..89059f37e2 100644 > --- a/sysdeps/ieee754/ldbl-128ibm-compat/Makefile > +++ b/sysdeps/ieee754/ldbl-128ibm-compat/Makefile OK, those make rules take a little time to digest. > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/Versions b/sysdeps/ieee754/ldbl-128ibm-compat/Versions > index 4aa34dbe59..6a27befed2 100644 > --- a/sysdeps/ieee754/ldbl-128ibm-compat/Versions > +++ b/sysdeps/ieee754/ldbl-128ibm-compat/Versions OK. This seems to be the accepted approach to expose the new ieee128 ABI. > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-asprintf.c b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-asprintf.c ... the ieee128-*printf.c wrappers all look OK. > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ibm128.c b/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ibm128.c > new file mode 100644 > index 0000000000..5de4ea3e7f > --- /dev/null > +++ b/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ibm128.c > @@ -0,0 +1 @@ > +#include > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ieee128.c b/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ieee128.c > new file mode 100644 > index 0000000000..5de4ea3e7f > --- /dev/null > +++ b/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ieee128.c > @@ -0,0 +1 @@ > +#include > diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ldbl-compat.c b/sysdeps/ieee754/ldbl-128ibm-compat/test-printf-ldbl-compat.c ... > + long double ld = -1; Is this the best value to use for compat tests? Would a value which produces unique output for the respective format if the wrong compiler flags are used? Or, maybe an extra header in *-ibm128.c and *-ieee128.c variants to sanity check __LDBL_MANT_DIG__? > diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc64/le/ldbl-128ibm-compat-abi.h b/sysdeps/unix/sysv/linux/powerpc/powerpc64/le/ldbl-128ibm-compat-abi.h > new file mode 100644 > index 0000000000..285216b231 > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc64/le/ldbl-128ibm-compat-abi.h > @@ -0,0 +1,8 @@ > +/* ABI version for long double switch to IEEE 128-bit floating point.. > + This is used by the Versions and math_ldbl_opt.h files in > + sysdeps/ieee754/ldbl-128ibm-compat/. It gives the ABI version where > + long double == ibm128 was replaced with long double == _Float128 > + for libm *l functions and libc functions using long double. */ > + > +#define LDBL_IBM128_VERSION GLIBC_2.31 > +#define LDBL_IBM128_COMPAT_VERSION GLIBC_2_31 > Should this part of the change be held off until all ldbl == ieee128 changes are in?