From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 9F59B38308A7; Tue, 28 Jun 2022 12:04:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9F59B38308A7 Received: from linux-libre.fsfla.org ([209.51.188.54]:37158 helo=free.home) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o69xX-00030T-Bi; Tue, 28 Jun 2022 08:04:52 -0400 Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 25SC4PMj925342 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jun 2022 09:04:28 -0300 From: Alexandre Oliva To: Jonathan Wakely Cc: "libstdc++" , gcc Patches Subject: Re: [PATCH] libstdc++-v3: check for openat Organization: Free thinker, not speaking for the GNU Project References: Errors-To: aoliva@lxoliva.fsfla.org Date: Tue, 28 Jun 2022 09:04:25 -0300 In-Reply-To: (Jonathan Wakely's message of "Tue, 28 Jun 2022 09:36:15 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2022 12:04:59 -0000 On Jun 28, 2022, Jonathan Wakely wrote: > I'll push this today. Thanks! > You can just use --enable-libstdcxx-debug Thanks again ;-) > Again, that test is *supposed* to return without creating the > destination. It's testing the failure case. Aha, and that's why one shouldn't debug something without looking at the code to see what it's *supposed* to do ;-) >> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc >> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc >> >> .../27_io/filesystem/operations/copy.cc:5[67]: void test01(): >> Assertion '!exists(to)' failed. > I don't know what 5[67] means Sorry for being unclear, it's just that the corresponding failing asserts are at different lines in the two mentioned testcases, and I tried to convey that fact with regexp notation. > Which suggests to me another problem with mkstemp / nonexistent_path. *lightbulb powers up* Now it all makes sense. It isn't *another* problem, that probably regressed when the mkstemp patch went in and so it got out of my radar and thus out of the patchset I used in subsequent test runs, but because of the way I use the testing system, the baseline on top of which the patchset was installed was still was still that of the previous nightly build, so I effectively dropped the mkstemp fix. And since when I joined this project this bug had already been fixed, I didn't associate the regressions with the patch. Apologies for the noise. Today's baseline, plus your _At_path patch and my remove_all patch, is all clear. Yay! -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about