From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 8774F3861904 for ; Fri, 29 Sep 2023 13:54:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8774F3861904 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-352697d8cb0so561885ab.1 for ; Fri, 29 Sep 2023 06:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695995679; x=1696600479; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jIIwIqQKQjJ+qd1EV7BqhMwUqzDXz40vuZ2MY7FYN9E=; b=JYfkl/PYhdipNXmo/n3LqOW8KxtaK+tZlsxoz6aIkxkWXoxMgCas4JJ543FlnxRoZ/ A8RLsu6YBw0mkuWrpQYcu/nM/RxpOsh4froDgN7EosxdRQoylxrZD5dGsOl70SneuEWn 8bX7O+xUn+H5CiHj5LO3RkNP25exwiSZAZxLcojwbOzYCjyY0nbLxYlGMvRfoTUONOYe KJ7SpAC6FZh6ngxbVv1meqMNvAuPY8lZkY5Q86CmXXde9oPXU+y3P2OWJvXZ/TyH/C9U Sf6jGQfQlDCp6A3cnmX4rP8KKqjQO1KjU1VzD1J+HqshZXZStNOPDmBHjjQyfdCwCeV3 1GDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695995679; x=1696600479; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jIIwIqQKQjJ+qd1EV7BqhMwUqzDXz40vuZ2MY7FYN9E=; b=pWMOgyA5WN/UU2gdiUK7ZUCpWIDJyzLTbjMrnzsdsUXSsDTdhdhAI9qQDDaFifADMJ eW4+G4Nu88P1WNhTEC+NhWNRfjfDF+lsAjyCgT3Fhp68TE/CjLowHbC7swiLQvcra5Bk fZplm0dsMNGyKfg9F34eovxaeb30zKahFv8KqSSG7CUQ3JgY9j9Peo2eZBQvHkti8D/L Ev3KVKdTBp0NAPlzI+uchndPNZd3OfKfOhwbSKXRjHGvw3yglysREiQAPvbtpdlhs2SB iDl4TryatjzCA0g78InMY8/ldHisAiC7HBZsRcASY5JrfEo57kKKnlBRLCHOpKJ4C78B XYyw== X-Gm-Message-State: AOJu0YyOKRZNrVtJ1V5G5A++le4+sJP5XVxuXqMq+vQuVp6aOpvN1pzA K8i1mX30A8OOTgEmPvN/DhAOEDzasCg= X-Google-Smtp-Source: AGHT+IGFUnFMQ8inhnlaeiHaDyb1lS3Kbajuzh/qhepiwqa1B2c5qmx2A30SvmMOsbZnTZKLO9DeQg== X-Received: by 2002:a05:6e02:1343:b0:348:cd6b:d593 with SMTP id k3-20020a056e02134300b00348cd6bd593mr3871967ilr.27.1695995678644; Fri, 29 Sep 2023 06:54:38 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id g2-20020a0566380c4200b0043a2736987fsm5248276jal.11.2023.09.29.06.54.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 06:54:38 -0700 (PDT) Message-ID: Date: Fri, 29 Sep 2023 07:54:36 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: committed [RISC-V]: Harden test scan patterns Content-Language: en-US To: Vineet Gupta , Joern Rennecke Cc: GCC Patches References: <2501e6a4-6f02-429f-8497-226a6b22403c@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,KAM_TK,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/27/23 17:21, Vineet Gupta wrote: > > > On 9/27/23 13:14, Jeff Law wrote: >>>> It would help to describe how these patterns were under specified so >>>> that folks don't continue to make the same mistake as new tests get >>>> added. >>> >>> dg-final scan-assembler, scan-assembler-not, and scan-assembler-times >>> use a tcl regular expression (often referred to abbreviated as RE), as >>> described in https://www.tcl.tk/man/tcl8.4/TclCmd/re_syntax.html . >>> >>> If your RE is not specific enough, it can match LTO information that the >>> compiler places into its assembly output when the relevant options are >>> provided, which is common when running tests where the test harness >>> iterates over a number of optimization option combinations. >>> Note that '.' is an atom that can match any character.  If you want to >>> match a dot specifically, you have to escape it with a backslash: '\.' . >>> When you are matching an instruction mnemonic, an effective way to >>> avoid matching in LTO information is to enforce matching of word start >>> (\m) and/or word end (\M) . >>> Note also that the backslash has to be quoted.  If the RE is enclosed in >>> '"' quotes, extra backslashes are needed.  That is not necessary when it >>> is enclosed in curly braces. >>> >>> For example, "ld.w" will be matched in: >>> >>> .ascii "h\227\022\212ld@w\251jr\254'\320\255vwj\252\026\016\364" >>> >>> If you write {\mld\.w\M} instead, you avoid this problem. >> OK.  So that naturally leads to the question, why aren't others seeing >> this, both in the RISC-V world and more generally.  I'm not aware of >> any case where I've run the testsuite and tripped over this issue, nor >> am I aware of anyone else tripping over it. > > Actually I did run into it. See commit ecfa870ff29d979bd2c ("RISC-V: > optim const DF +0.0 store to mem [PR/110748]") where a false failure was > triggered due to these random LTO strings and needed adjusting. Ah! Good (I suppose). > > -/* { dg-final { scan-assembler-not "sw" } } */ > -/* { dg-final { scan-assembler-not "fld" } } */ > -/* { dg-final { scan-assembler-not "fsd" } } */ > -/* { dg-final { scan-assembler-not "lw" } } */ > +/* { dg-final { scan-assembler-not "\tsw\t" } } */ > +/* { dg-final { scan-assembler-not "\tfld\t" } } */ > +/* { dg-final { scan-assembler-not "\tfsd\t" } } */ > +/* { dg-final { scan-assembler-not "\tlw\t" } } */ The downside of this approach (which I nearly suggested to Joern) is that it relies on tabs before/after the mnemonic. That would also imply a review policy to ensure we always use tabs -- and there's going to be cases where spotting a tab vs space is going to be tough in a patch review, particularly after the mnemonic. We could instead match a regexp that allows spaces or tabs, but at that point I doubt it's simpler than Joern's approach. So I recommend we go forward with Joern's approach (so consider that an ACK for the trunk). Joern can you post a follow-up manual twiddle so that other ports can follow your example and avoid this problem? THanks, jeff