From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 28A833858D28 for ; Mon, 25 Apr 2022 23:00:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28A833858D28 Received: by mail-ej1-x635.google.com with SMTP id i27so32483054ejd.9 for ; Mon, 25 Apr 2022 16:00:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tzTQ2Mpoe+n8/+fu1zGO72hdL49arVjBQRB2ckFBkec=; b=bEcKykHRWVoCN9EVLm+6hMHScvZbN0FXtalty3hh5pqumG8rgGKbjE2SbCJARP+zpk Dnj+bhjNadmkNAEetcrzrCkdGYHFVYJ5uILVwXO87TaKhd7yWqJwRmyi9qQd0EwcV38e 3JfU07mzcy7P8nTTPiBMmADJPcaXWWcmQ+aaosENqnEuDcRHHdysIKgWfrZi4MMWy+YS pCXDvNVbFj3x3b5i3KOk+hjcPHswNDJEgOIgUslXMMMZOeQUsMTcY5bGdY+9hUTlOQ+H UdwCher87srqqqCKD29uVQWn4slBYTCJIIxRnL7Vp/Lf6j3qxla7PLUakaRqaKBplzoq b+RQ== X-Gm-Message-State: AOAM532xkMoFoEOqCN3gVKGXaoceJsm4KieSacr+kOSZDTkrRvnlr/3R NbFKPuZnanxJ7otK7l22OL4= X-Google-Smtp-Source: ABdhPJzxJmwYWPdkC/VFS/fa7ikC9o+oMTCMUDLxPHfAReJEzFzP9fxfVaFyQH6RDi41+E185Z1qPw== X-Received: by 2002:a17:907:8a1f:b0:6f3:9199:5f2d with SMTP id sc31-20020a1709078a1f00b006f391995f2dmr7907982ejc.83.1650927632924; Mon, 25 Apr 2022 16:00:32 -0700 (PDT) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id p10-20020a170906604a00b006e07c76f3d7sm3994887ejj.210.2022.04.25.16.00.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Apr 2022 16:00:32 -0700 (PDT) Date: Tue, 26 Apr 2022 01:00:29 +0200 From: Bernhard Reutner-Fischer To: Mike Stump Cc: rep.dot.nop@gmail.com, GCC Patches , Rainer Orth , Jeff Law Subject: testsuite -fno-file [was: Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests] Message-ID: <20220426010029.2b476337@nbbrfq> In-Reply-To: References: <1466278273-7014-1-git-send-email-rep.dot.nop@gmail.com> <44774FBA-55E9-4CBB-8EB3-0C67BCC09E62@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , X-List-Received-Date: Mon, 25 Apr 2022 23:00:37 -0000 On Fri, 2 Feb 2018 14:25:22 +0100 Bernhard Reutner-Fischer wrote: > On 19 June 2016 at 22:21, Mike Stump wrote: > > On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer wrote: =20 > >> > >> A branch with a name matching scan-assembler pattern triggers > >> inappropriate FAIL. =20 > > =20 > >> The patch below adds -fno-ident if a testcase contains one of > >> scan-assembler, scan-assembler-not or scan-assembler-times. =20 > > > > Kinda gross. I'd like to consensus build a little, as I don't know tha= t I have a better solution than the solution you propose to fix the issue. = I'd love it if one or more of Jacob, Law and Richard can chime in on direc= tion here. I'll have to think about this some more and see if I can come u= p with something that I like better. > > > > If no one has a better solution, I'll approve the proposed solution. L= et's give people a little time to chime in. =20 >=20 > Given the overwhelming silence this proposal has received, i take it > for granted that folks are thrilled and even up until now speechless > :) >=20 > So how should we proceed with -fno-ident. > And, btw, -fno-file to inhibit .file directives for the same reason, AFAICS we still do not pass -fno-file in tests. Every now and then this still results in unnecessary, silly workarounds like this one: > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01785.html and all our which we should not have to afford. > ugly filenames like gcc.target/powerpc/swps-p8-36.c which strive to > workaround the assembler-scans. >=20 > All those non-automatic hacks like naming swap() tests swps-, > uglifying scan-patterns (which are not terribly straight forward to > read anyway even without uglifying them) are error prone and costly. > IMHO we should make sure time is spent for useful stuff and not be > wasted to fight our very own testsuite. >=20 > -fno-ident ok for stage1? We've fixed the ident thing some time ago. > What about -fno-file? Clever alternative suggestions? Don't care? We still didn't fix the .file directives in assembler output. It's about the same as always. See if the target supports -fno-file and/or -ffile. If the testcase does NOT specify -fno-file or -ffile =C2=B9) then pass an appropriate default like -fno-file, otherwise do not add anything. =C2=B9) The real complication seems to be that there is neither a -fno-file nor a (let's say) -ffile=3Dfoo.c implemented anywhere. And TBH we do not need it nor want it for the purpose at hand. That suggests that it would probably be cheaper to run sed on the (remote) output file -- or do it locally and only then copy it to the remote. The net effect being that .file directives in the testsuite are gone and can no longer compromise tests. thanks,