From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 6BD8A385DC04 for ; Wed, 27 Sep 2023 23:21:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BD8A385DC04 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-578a62c088cso10164171a12.1 for ; Wed, 27 Sep 2023 16:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1695856888; x=1696461688; 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=yZIzFE54j3Itco3Mw5S47PpoKIM3WEQyRXXW0g1xKgs=; b=m6B7MKXyHaH3+vZNmt4ZnTf56WGNjdAqvM7Q7pqTNndPipl/9lVNvfxEzr+DmqUv8X q4KBblWBdfzD+2CrD4xUUN+OpIWbK4MN0c74rrwccM6rFylHR9lnUng80pJXu9LUHMVS UZN4x4Flpl0i/0WCZCqkWjBMHK3JHy6nBXVZCGhY8lkcc312qNm0D1eJaEi0RKgJkaHn PpQ4dK+m1lOwsCuRgPjNPD5sVT78lnJiUu47onVkRiqX1/5ZxDGLQTYYw59OhwC0X/+M /OrUAwzznZCYeTqbGE5ij6WFN503Lrb/9QlrcEznlj92gdNla0myhRjukAuKoZCmJOzf Hg3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695856888; x=1696461688; 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=yZIzFE54j3Itco3Mw5S47PpoKIM3WEQyRXXW0g1xKgs=; b=v3qQzlu2/39U/8uogD44Pnt3gwskx+Ren3nK9lFdn07WWsAEykX4EOzpp+xlC9e04m st3lMNdhrRYkNFYOd2tUON0s2giPfR2wAR7GmObTOgY9uEOO4k9y/4fWAZZhbQVnJ4/V rYp+jxxld12DUDIMp5gaMcu+XWwWjG2pNea+uddTKDTrzgqigjKYGQKmdDWhJS7uZPus BT8vaB16ldaOou3Y0KJLh+bChPumffSTAuU1Fri7oubB80x8BUVuyX+tHKM7nk+B1Huc e2VbrLR2PNXJ35cLLUREz1SnlPQlRdskOUzqCXk346P5KuruVMd2jRnE1eK5GrhABYft ho7g== X-Gm-Message-State: AOJu0Yxzc2sV4p7vVlzv/CdkyC0Zig/DKkGvjqJdeQJ0pt+x4BdE+kCY wCD0V/gpjzP34LG2jeCCeVYemQ== X-Google-Smtp-Source: AGHT+IGXUHnQEW0vFzoP/Hs4QmLRpyYS2qPZ/NO9W/dBvCTWB8eIDghJfmwlnxFBBDZjFZLkjSjtNQ== X-Received: by 2002:a17:90a:e517:b0:279:dae:2d3f with SMTP id t23-20020a17090ae51700b002790dae2d3fmr500250pjy.22.1695856887947; Wed, 27 Sep 2023 16:21:27 -0700 (PDT) Received: from [192.168.50.117] (c-98-210-197-24.hsd1.ca.comcast.net. [98.210.197.24]) by smtp.gmail.com with ESMTPSA id mg6-20020a17090b370600b0027722832498sm7747538pjb.52.2023.09.27.16.21.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Sep 2023 16:21:27 -0700 (PDT) Message-ID: Date: Wed, 27 Sep 2023 16:21:26 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: committed [RISC-V]: Harden test scan patterns Content-Language: en-US To: Jeff Law , Joern Rennecke Cc: GCC Patches References: <2501e6a4-6f02-429f-8497-226a6b22403c@gmail.com> From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_SHORT,KAM_TK,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. -/* { 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" } } */