From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id EF34B3858C20; Sat, 1 Oct 2022 11:02:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF34B3858C20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29125K5A009083; Sat, 1 Oct 2022 13:02:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=/oChYIcBZ+fFljpE8l9+i8kp4iRYfJiPLZuCl5iHWKc=; b=QsDO9g4/nj0wkG8RU5CQG2pxzvSkm1LRXJ4J5+7+3/ntJMFnRWCd3zreTXrzQuaNkYTX 6haZYgYHCSx/BXvmjCMJ87a4SpiheZB0nKcYWSx1zpF4STUdedw7goOOzsUmDwM+7ipj vihUDzOigBA6rmeoZBW9wLcvLLaNZt50/oSTjU02NZPzZ0Pbjk8NSF0fLC9G8Md8fWGD 23AsJ8Dbv8NjOF1VdZCGvF7/HUOGgTlrGIG2PF8zwbeZ44Bwm5/mHHMZ9LhrdsOefaxK 3P7QzJAlCR1QELnV5pXlPaFqebS2kFse7QAa2Firkc61SdCrF+u9eYQTLW1S92DIXCEf kQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3jxcehhmgb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Oct 2022 13:02:28 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A1BBA10002A; Sat, 1 Oct 2022 13:02:25 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 1F5C621A232; Sat, 1 Oct 2022 13:02:25 +0200 (CEST) Received: from [10.252.20.206] (10.75.127.50) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.31; Sat, 1 Oct 2022 13:02:23 +0200 Message-ID: Date: Sat, 1 Oct 2022 13:02:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH] testsuite: Windows paths use \ and not / Content-Language: en-US To: Jonathan Wakely , Jonathan Wakely CC: Jakub Jelinek , libstdc++ , , References: <20220930153845.2268381-1-torbjorn.svensson@foss.st.com> From: Torbjorn SVENSSON In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG2NODE3.st.com (10.75.127.6) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-10-01_07,2022-09-29_03,2022-06-22_01 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,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 List-Id: Hi, I'm really sorry for the mess. I did test my patch, but I just looked for the PASS/FAIL for the excess errors and missed that there was an error with the pattern. In the end, the patch that you pushed is much better. Thanks for fixing the issue in my absence. Kind regards, Torbjörn On 2022-09-30 23:07, Jonathan Wakely wrote: > On Fri, 30 Sept 2022 at 19:13, Jonathan Wakely via Libstdc++ > wrote: >> >> On Fri, 30 Sept 2022 at 19:07, Jonathan Wakely wrote: >>> >>> On Fri, 30 Sept 2022 at 19:04, Jonathan Wakely wrote: >>>> >>>> On Fri, 30 Sept 2022 at 18:55, Jakub Jelinek wrote: >>>>> >>>>> On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches wrote: >>>>>> On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote: >>>>>>> >>>>>>> On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON >>>>>>> wrote: >>>>>>>> >>>>>>>> libstdc++-v3/testsuite: >>>>>>>> >>>>>>>> * 20_util/bind/ref_neg.cc: Prune Windows paths too. >>>>>>> >>>>>>> Please CC the libstdc++ for libstdc++ patches. >>>>>>> >>>>>>> OK for trunk, thanks. >>>>>> >>>>>> I'm seeing errors now on x86_64-linux: >>>>>> >>>>>> ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for " >>>>>> dg-prune-output 53 "[/\\](functional|bits/invoke.h):" " >>>>>> >>>>>> ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for " >>>>>> dg-prune-output 53 "[/\\](functional|bits/invoke.h):" " >>>>> >>>>> Bet it should be >>>>> // { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" } >>>>> or so. Completely untested. >>>> >>>> That fixes the error, but now the regex doesn't match so there are >>>> still excess errors. It needs to be: >>>> >>>> // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" } >>>> >>>> Without any regex special characters, there's an implicit .* before >>>> and after the pattern. But when you use any regex special characters >>>> in the pattern, it stops working. I can't remember why. I figured it >>>> out once. >>> >>> It looks like just adding .* at the start is enough: >>> >>> // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):" } >>> >>> But that's so ugly, I'm tempted to replace that prune with something different. >> >> I'll finish testing this and push it. > > I committed this instead, with no .* in the pattern.