From patchwork Sun Nov 20 01:50:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 60886 Return-Path: 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 4586E3895FFA for ; Sun, 20 Nov 2022 01:51:29 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id 051C23894C1F for ; Sun, 20 Nov 2022 01:50:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 051C23894C1F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pj1-x102a.google.com with SMTP id m14so7668344pji.0 for ; Sat, 19 Nov 2022 17:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=0yvxWKJmPLBMHcs0q6Nuwbv8UHlNeYyCsY/Q7BEXk9o=; b=LzEv+yyPVCTGEasVPKiKGtZ/W+5qSOWzvvR6yUjeU7tRLbg6Q6f6JQ7u4ldqIHV+gi kzv/Mc6H2TxT4ip3mo87Lj1ZOzRlxYLa2tIxwlfKFaK+jCJVMfYEkou3Px2yidCuwA39 rcIOECFTW7uDyb1233ZbaBP9HcIffYqWEXXLv+BcJj9O1xMlnQJ0cvaIhruP2DAblScw +LhY6GcbLhiqhWQ2+xTq5RcgPEhl+S1wCEha6qDOwO85ZQCv2Yh/weCzvJSNDRcW94yx ebPN3eFZqU+PSBB+KPkNy+8HOY28Fyvz5FSIIhez/ovhvkas/ePv8l6xkWTShp/3q98w 6xYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0yvxWKJmPLBMHcs0q6Nuwbv8UHlNeYyCsY/Q7BEXk9o=; b=BLO5OhwkMwX4DmLlzMnGuh0rwq7LJrYrTjH5kixsSraFlYdP6KdmdWLJwar3TVaSbq CCzLMhPvdxRZstEk196NxCxNhc23OZUhfMtO/Su2u3Egsa/nDUYlQQw2kSokq/HRGRnR 0rB24//l9atM8ZbnJrWCaFsDu7p7U+WABGr8W0lUU18Vm5x0tzRpFcrKE9oN70VwARjD 6wjpN0Cv134bmWrYghPFXI2OGrrm8w1dNpQ0UvKQ3h/0dh2HXHFHh5Y9EyxxpD9voZs0 ZySpepbfUIkpVERh5xVJdgMUIjlZ//u4APVBDMQwLfS1Hhlsz3nY+nLxONr0CudRWCwX J+qA== X-Gm-Message-State: ANoB5plhTViwviznUJDVc99yqVYDlK76ZVQWJxMxw6z+oiul4QnZ3rNd U5RfElSUpJi80SViMAZ6hzB7yrYOQhoAxg== X-Google-Smtp-Source: AA0mqf7s0eoQ6fwDBjI6we/49g+LWSM/F4+/Kh02KNq5PcpiMJzeHgiNg5Q4FuwMkoltGD1kWKDnoQ== X-Received: by 2002:a17:902:ec8d:b0:188:59d2:33e with SMTP id x13-20020a170902ec8d00b0018859d2033emr5675852plg.142.1668909054451; Sat, 19 Nov 2022 17:50:54 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id i9-20020a635409000000b00476d1385265sm4971409pgb.25.2022.11.19.17.50.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Nov 2022 17:50:53 -0800 (PST) Message-ID: <3ebe79f4-af7d-0817-456c-331dfb2e3f56@ventanamicro.com> Date: Sat, 19 Nov 2022 18:50:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US From: Jeff Law Subject: [committed] Fix test to not depend on DECL_UIDs To: "gcc-patches@gcc.gnu.org" X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" The tester started tripping this on s390-linux-gnu: Tests that now fail, but worked before (19 tests):  gcc.dg/pr96542.c scan-tree-dump-times evrp "254" 2 The problem is we search for "254" in the dump file.  The dump file contains UIDs for function declarations.  So changes in the number of predefined DECL nodes can make the test pass or file depending on whether or not a decl with a UID containing "254" shows up.  Like this: ;; Function foo (foo, funcdef_no=0, decl_uid=2542, cgraph_uid=1, symbol_order=0) ISTM the test wants to look for a "return 254" rather than just "254".    I added a change for that to the tester.  Naturally that fixed the test on s390 and the dozen or so targets I tested didn't show any regressions. Installing on the trunk, Jeff commit 53a6b2e0d3405c2a4de28a3e065837d5d55f4336 Author: Jeff Law Date: Sat Nov 19 20:47:20 2022 -0500 Fix test to not depend on DECL_UIDs The tester started tripping this on s390-linux-gnu: Tests that now fail, but worked before (19 tests): gcc.dg/pr96542.c scan-tree-dump-times evrp "254" 2 The problem is we search for "254" in the dump file. The dump file contains UIDs for function declarations. So changes in the number of predefined DECL nodes can make the test pass or file depending on whether or not a decl with a UID containing "254" shows up. Like this: ;; Function foo (foo, funcdef_no=0, decl_uid=2542, cgraph_uid=1, symbol_order=0) ISTM the test wants to look for a "return 254" rather than just "254". I added a change for that to the tester. Naturally that fixed the test on s390 and the dozen or so targets I tested didn't show any regressions. gcc/testsuite * gcc.dg/pr96542.c: Avoid falsely matching DECL_UIDs with the number 254 in them. diff --git a/gcc/testsuite/gcc.dg/pr96542.c b/gcc/testsuite/gcc.dg/pr96542.c index 5014f2acad8..0aad2e9494e 100644 --- a/gcc/testsuite/gcc.dg/pr96542.c +++ b/gcc/testsuite/gcc.dg/pr96542.c @@ -22,6 +22,6 @@ baz (unsigned int x) return (-1U >> x) * 16; } -/* { dg-final { scan-tree-dump-times "254" 2 "evrp" } } */ +/* { dg-final { scan-tree-dump-times "return 254" 2 "evrp" } } */ /* { dg-final { scan-tree-dump "= PHI <32.*, 4294967280" "evrp" } } */