public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jlaw@ventanamicro.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: [committed] Fix test to not depend on DECL_UIDs
Date: Sat, 19 Nov 2022 18:50:52 -0700	[thread overview]
Message-ID: <3ebe79f4-af7d-0817-456c-331dfb2e3f56@ventanamicro.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

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



[-- Attachment #2: P --]
[-- Type: text/plain, Size: 1568 bytes --]

commit 53a6b2e0d3405c2a4de28a3e065837d5d55f4336
Author: Jeff Law <jeffreyalaw@gmail.com>
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" } }  */
 

                 reply	other threads:[~2022-11-20  1:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ebe79f4-af7d-0817-456c-331dfb2e3f56@ventanamicro.com \
    --to=jlaw@ventanamicro.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).