Message ID | 20210107215100.1594273-1-shorne@gmail.com |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@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 F10313971831; Thu, 7 Jan 2021 21:51:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F10313971831 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610056269; bh=VECqsOCzbdCgj/knO8n1wGISb+6DL4KUU2jJj+zePUE=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=RYT9h9SmqaOcHrjFsbmLzp7wxTQFzM1atkY6rrgZp8lH9K6LxHjcvY6GGAqZSNS+r m6PZ8I8Hw9GlRR9R21nX5zomW7nT4iRmY07QCqyKl2cOBFE+7PggoN5F+evRdjE8iR edz/l5pVeAQbyRCaxzwDMH3XSPfKfVcWoNRscuLU= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 7A08C3858023 for <libc-alpha@sourceware.org>; Thu, 7 Jan 2021 21:51:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7A08C3858023 Received: by mail-pj1-x1032.google.com with SMTP id m5so4877125pjv.5 for <libc-alpha@sourceware.org>; Thu, 07 Jan 2021 13:51:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=VECqsOCzbdCgj/knO8n1wGISb+6DL4KUU2jJj+zePUE=; b=iXi5X7A24HCD4AoR3B/MyBmYd6yKuwVojjlN71f9wFdcil+OUKD4U0/dzKzCyVtd+U x1EVJvOsVeCopDk9tMOxW283RicoSCXU/aX6/jHQ0z2N2J83g/aX4/z0O2yv/TccX3Pa 9scrPK12XhO1WZc6/jXO9fh6WyT13gfsXwnhvrXA6SRhPtNiawp4FwTk2qFjPCLQPUyE qleiNjbtsqsmpzOXXgANAS3U1U4FnpPO29Rw4NstdYbDw5vHkm6NEH859iy4kXCcoh1W L23EfPVbPEbPyRiEpvXPqo4dit4/IjoTnCvp2truw6UKnJ2EiyaJXpUigG1+RKFUbcBQ Vnew== X-Gm-Message-State: AOAM5315RuAdT821Q/hNpqlgru+2eX1UsbEYsax5g2AIFj67L6bArqBR FC89cBUeqdM5k7CCp8U1KL7oiKPNs3E= X-Google-Smtp-Source: ABdhPJxq9GyZGkNgbT3Rh6vnoqMvkseTIHYYdyX7F1MMfP+t8v+P9/BZ4d1zzdVWQnDNOHYe5slfDg== X-Received: by 2002:a17:90a:c20b:: with SMTP id e11mr463199pjt.43.1610056265334; Thu, 07 Jan 2021 13:51:05 -0800 (PST) Received: from localhost (g178.219-103-173.ppp.wakwak.ne.jp. [219.103.173.178]) by smtp.gmail.com with ESMTPSA id p15sm7318808pgl.19.2021.01.07.13.51.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jan 2021 13:51:04 -0800 (PST) To: GLIBC patches <libc-alpha@sourceware.org> Subject: [RFC PATCH] math/testtgmath2: Fix breakage on fabs Vldouble1 due to optimization Date: Fri, 8 Jan 2021 06:51:00 +0900 Message-Id: <20210107215100.1594273-1-shorne@gmail.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 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> From: Stafford Horne via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Stafford Horne <shorne@gmail.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
[RFC] math/testtgmath2: Fix breakage on fabs Vldouble1 due to optimization
|
|
Commit Message
Stafford Horne
Jan. 7, 2021, 9:51 p.m. UTC
I have been testing with GCC trunk and GLIBC master while working on OpenRISC ports. This test has been failing which fabs not being called, I am guessing this is due to new optimizations in GCC that are causing the Vldouble1 call to also be optimized out now, but I may be wrong. No other tests in math/* are failing for me exept for this one now. FAIL: math/test-tgmath2 original exit status 1 wrong function called, fabs (ldouble) failure on line 174 Note: I also added some details to the FAIL line to help track what issue caused the failure. --- Has anyone else seen this? math/test-tgmath2.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Comments
On Fri, 8 Jan 2021, Stafford Horne via Libc-alpha wrote: > I have been testing with GCC trunk and GLIBC master while working on > OpenRISC ports. This test has been failing which fabs not being called, > I am guessing this is due to new optimizations in GCC that are causing > the Vldouble1 call to also be optimized out now, but I may be wrong. This test is built with -fno-builtin. If a function call is optimized out, that sounds like a GCC bug which should be fixed there.
On Fri, Jan 8, 2021, 7:53 AM Joseph Myers <joseph@codesourcery.com> wrote: > On Fri, 8 Jan 2021, Stafford Horne via Libc-alpha wrote: > > > I have been testing with GCC trunk and GLIBC master while working on > > OpenRISC ports. This test has been failing which fabs not being called, > > I am guessing this is due to new optimizations in GCC that are causing > > the Vldouble1 call to also be optimized out now, but I may be wrong. > > This test is built with -fno-builtin. If a function call is optimized > out, that sounds like a GCC bug which should be fixed there. > (Replying on phone) Thanks, that gives me a clue. -stafford >
On Thu, Jan 07, 2021 at 10:53:04PM +0000, Joseph Myers wrote: > On Fri, 8 Jan 2021, Stafford Horne via Libc-alpha wrote: > > > I have been testing with GCC trunk and GLIBC master while working on > > OpenRISC ports. This test has been failing which fabs not being called, > > I am guessing this is due to new optimizations in GCC that are causing > > the Vldouble1 call to also be optimized out now, but I may be wrong. > > This test is built with -fno-builtin. If a function call is optimized > out, that sounds like a GCC bug which should be fixed there. > > -- > Joseph S. Myers > joseph@codesourcery.com Hello, I did some more investigation but I can not quite understand what is going wrong here. When I compile with or1k-smh-linux-gnu-gcc -fdump-tree-all-all, I can see that the call to fabs is being removed during the FRE (Full redundancy elimination) pass [note 3]. This looks to be because ldouble and double are the same on my architecture, this means the call to "fabs (Vdouble1)" and "fabs (Vldouble1)" become the same thing and the compiler removes the second redundant call (with -Og). You mention -fno-builtin, but I still see __builtin_tgmath being used which is what is used in tgmath.h [note 4]. Perhaps I am misunderstanding but -fno-builtin does not elliminate the usage of __builtin_tgmath. That said, I think the compiler is correct but my patch is wrong. I will try to think of something else. Notes: 1. Compile command line: or1k-smh-linux-gnu-gcc -mcmov -mror -mrori -msfimm -mshftimm -msext \ -B/home/shorne/work/gnu-toolchain/local/bin/ test-tgmath2.c -c \ -std=gnu11 -fgnu89-inline \ -g -Og -Wall -Wwrite-strings -Wundef -fmerge-all-constants \ -frounding-math -fno-stack-protector -Wstrict-prototypes \ -Wold-style-definition -fmath-errno \ -fno-builtin \ -DNO_LONG_DOUBLE \ -I../include ... -DMODULE_NAME=testsuite -include ../include/libc-symbols.h \ -DTOP_NAMESPACE=glibc -I../soft-fp \ -o /home/shorne/work/gnu-toolchain/build-glibc/math/test-tgmath2.o \ -fdump-tree-all-all 2. I changed the test_fabs function to just call: TEST (fabs (vcldouble1), ldouble, cabs); TEST (fabs (Vfloat1), float, fabs); TEST (fabs (Vdouble1), double, fabs); TEST (fabs (Vldouble1), ldouble, fabs); 3. In the tree dump I see: grep 'fabs' ../../build-glibc/math/test-tgmath2.c.03*t.* ../../build-glibc/math/test-tgmath2.c.034t.ethread: ;; Function fabs (fabs, funcdef_no=28, decl_uid=1116, cgraph_uid=29, symbol_order=84) doubleD.25 fabs (doubleD.25 xD.25027) ;; Function fabsf (fabsf, funcdef_no=41, decl_uid=1550, cgraph_uid=42, symbol_order=97) floatD.24 fabsf (floatD.24 xD.25074) ;; Function test_fabs (test_fabs, funcdef_no=13, decl_uid=5158, cgraph_uid=14, symbol_order=69) intD.1 test_fabs (const intD.1 Vint4D.5156, const long long intD.10 Vllong4D.5157) _9 = fabsfD.1550 (1.0e+0); _14 = fabsD.1116 (1.0e+0); _19 = fabsD.1116 (1.0e+0); _31 = test_fabsD.5158 (vint1.3287_3, vllong1.3288_4); ../../build-glibc/math/test-tgmath2.c.037t.fre1: ;; Function fabs (fabs, funcdef_no=28, decl_uid=1116, cgraph_uid=29, symbol_order=84) doubleD.25 fabs (doubleD.25 xD.25027) ;; Function fabsf (fabsf, funcdef_no=41, decl_uid=1550, cgraph_uid=42, symbol_order=97) floatD.24 fabsf (floatD.24 xD.25074) ;; Function test_fabs (test_fabs, funcdef_no=13, decl_uid=5158, cgraph_uid=14, symbol_order=69) Value numbering stmt = _9 = fabsf (1.0e+0); Value numbering stmt = _14 = fabs (1.0e+0); Value numbering stmt = _19 = fabs (1.0e+0); Replaced fabs (1.0e+0) with _14 in all uses of _19 = fabs (1.0e+0); Removing dead stmt _19 = fabs (1.0e+0); intD.1 test_fabs (const intD.1 Vint4D.5156, const long long intD.10 Vllong4D.5157) _9 = fabsfD.1550 (1.0e+0); _14 = fabsD.1116 (1.0e+0); Value numbering stmt = _31 = test_fabs (vint1.3287_3, vllong1.3288_4); _31 = test_fabsD.5158 (vint1.3287_3, vllong1.3288_4); 4. If I look at the expressions for the above: printfD.4229 ("%s failure on line %d\n", "wrong function called, cabs (ldouble) - __builtin_tgmath (fabsf, fabs, fabsl, fabsf32, fabsf64, fabsf32x, cabsf, cabs, cabsl, cabsf32, cabsf64, cabsf32x, ((vcldouble1)))", 173); printfD.4229 ("%s failure on line %d\n", "wrong function called, fabs (float) - __builtin_tgmath (fabsf, fabs, fabsl, fabsf32, fabsf64, fabsf32x, cabsf, cabs, cabsl, cabsf32, cabsf64, cabsf32x, ((Vfloat1)))", 174); printfD.4229 ("%s failure on line %d\n", "wrong function called, fabs (double) - __builtin_tgmath (fabsf, fabs, fabsl, fabsf32, fabsf64, fabsf32x, cabsf, cabs, cabsl, cabsf32, cabsf64, cabsf32x, ((Vdouble1)))", 175); printfD.4229 ("%s failure on line %d\n", "wrong function called, fabs (ldouble) - __builtin_tgmath (fabsf, fabs, fabsl, fabsf32, fabsf64, fabsf32x, cabsf, cabs, cabsl, cabsf32, cabsf64, cabsf32x, ((Vldouble1)))", 176); -Stafford
On Sat, 9 Jan 2021, Stafford Horne via Libc-alpha wrote: > When I compile with or1k-smh-linux-gnu-gcc -fdump-tree-all-all, I can see that > the call to fabs is being removed during the FRE (Full redundancy elimination) > pass [note 3]. This looks to be because ldouble and double are the same on my > architecture, this means the call to "fabs (Vdouble1)" and "fabs (Vldouble1)" > become the same thing and the compiler removes the second redundant call (with > -Og). I'd expect calls to fabs and fabsl, not two calls to fabs, once the front end has done the tgmath.h processing (given a GCC 8 or later compiler so it's not based on sizeof, anyway) and before any GIMPLE optimizations have run. > You mention -fno-builtin, but I still see __builtin_tgmath being used which is > what is used in tgmath.h [note 4]. Perhaps I am misunderstanding but > -fno-builtin does not elliminate the usage of __builtin_tgmath. __builtin_tgmath is a syntax construct (not actually a built-in function) that only exists at front-end level. -fno-builtin should mean that the compiler doesn't know that fabs and fabsl do the same thing. So the first question is what the calls look like before any GIMPLE optimizations. Is the issue that the asm redirections in the headers mean that the call to fabsl is set up to call fabs at the assembler level and the compiler is thus noticing they are the same function, based on the asm redirection rather than on being built-in? If so, maybe the test should be set up so that double and long double calls always use different function arguments to avoid such an optimization.
diff --git a/math/test-tgmath2.c b/math/test-tgmath2.c index 14a3453169..a9ede4ece7 100644 --- a/math/test-tgmath2.c +++ b/math/test-tgmath2.c @@ -122,7 +122,7 @@ int counts[Tlast][C_last]; __asm __volatile ("" : : "r" (&texpr)); \ if (count != 1 || counts[T##type][C_##fn] != 1) \ { \ - FAIL ("wrong function called"); \ + FAIL ("wrong function called, "#fn" ("#type")"); \ memset (counts, 0, sizeof (counts)); \ } \ count = 0; \ @@ -171,14 +171,15 @@ test_fabs (const int Vint4, const long long int Vllong4) TEST (fabs (vcldouble1), ldouble, cabs); TEST (fabs (Vfloat1), float, fabs); TEST (fabs (Vdouble1), double, fabs); - TEST (fabs (Vldouble1), ldouble, fabs); #ifndef __OPTIMIZE__ /* GCC is too smart to optimize these out. */ TEST (fabs (Vint1), double, fabs); TEST (fabs (Vllong1), double, fabs); + TEST (fabs (Vldouble1), ldouble, fabs); #else TEST_TYPE_ONLY (fabs (vllong1), double); TEST_TYPE_ONLY (fabs (vllong1), double); + TEST_TYPE_ONLY (fabs (Vldouble1), ldouble); #endif TEST (fabs (Vint4), double, fabs); TEST (fabs (Vllong4), double, fabs);