From patchwork Fri Mar 6 20:37:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Paul E. Murphy" X-Patchwork-Id: 38470 X-Patchwork-Delegate: tuliom@linux.vnet.ibm.com Received: (qmail 2954 invoked by alias); 6 Mar 2020 20:37:29 -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 2930 invoked by uid 89); 6 Mar 2020 20:37:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=manipulating, 14711 X-HELO: mx0b-001b2d01.pphosted.com From: "Paul E. Murphy" To: libc-alpha@sourceware.org Subject: [PATCH 02/13] Fix tests which expose ldbl -> _Float128 redirects Date: Fri, 6 Mar 2020 14:37:10 -0600 Message-Id: <20200306203721.15886-3-murphyp@linux.vnet.ibm.com> In-Reply-To: <20200306203721.15886-1-murphyp@linux.vnet.ibm.com> References: <20200306203721.15886-1-murphyp@linux.vnet.ibm.com> MIME-Version: 1.0 The ldbl redirects for ieee128 have some jagged edges when inspecting and manipulating symbols directly. e.g asprintf is unconditionally redirected to __asprintfieee128 thus any tests relying on GCC's redirect behavior will encounter problems if they inspect the symbol names too closely. I've mitigated tests which expose the limitations of the ldbl -> f128 redirects by giving them knowledge about the redirected symbol names. Hopefully there isn't much user code which depends on this implementation specific behavior. Reviewed-by: Tulio Magno Quites Machado Filho --- elf/tst-addr1.c | 11 +++++++++++ stdio-common/tst-vfprintf-user-type.c | 4 ++++ 2 files changed, 15 insertions(+) diff --git a/elf/tst-addr1.c b/elf/tst-addr1.c index 68ff74aabd..27dc0f00f4 100644 --- a/elf/tst-addr1.c +++ b/elf/tst-addr1.c @@ -12,6 +12,16 @@ do_test (void) return 1; } printf ("found symbol %s in %s\n", i.dli_sname, i.dli_fname); + if (i.dli_sname == NULL) + return 1; + +#if __LONG_DOUBLE_USES_FLOAT128 == 1 + /* On architectures which redirect long double to + _Float128 (e.g powerpc64le), printf will resolve + to __printfieee128 due to header redirects. There + is no _IO_printfieee128 alias. */ + return strcmp (i.dli_sname, "__printfieee128") != 0; +#else return i.dli_sname == NULL || (strcmp (i.dli_sname, "printf") != 0 /* On architectures which create PIC code by default @@ -20,6 +30,7 @@ do_test (void) are aliased and which one comes first in the hash table is up to the linker. */ && strcmp (i.dli_sname, "_IO_printf") != 0); +#endif } #include diff --git a/stdio-common/tst-vfprintf-user-type.c b/stdio-common/tst-vfprintf-user-type.c index 6c840fe04b..40d714fdb1 100644 --- a/stdio-common/tst-vfprintf-user-type.c +++ b/stdio-common/tst-vfprintf-user-type.c @@ -147,7 +147,11 @@ do_test (void) /* Alias declaration for asprintf, to avoid the format string attribute and the associated warning. */ +#if __LONG_DOUBLE_USES_FLOAT128 == 1 + extern int asprintf_alias (char **, const char *, ...) __asm__ ("__asprintfieee128"); +#else extern int asprintf_alias (char **, const char *, ...) __asm__ ("asprintf"); +#endif TEST_VERIFY (asprintf_alias == asprintf); char *str = NULL; TEST_VERIFY (asprintf_alias (&str, "[[%P]]", 123L, 456.0) >= 0);