From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 2482B3858C01; Wed, 11 Oct 2023 04:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2482B3858C01 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-wm1-x335.google.com with SMTP id 5b1f17b1804b1-405505b07dfso2858615e9.0; Tue, 10 Oct 2023 21:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696999745; x=1697604545; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=AffNU6tT3rlGnQ3XqLjFz/EUfJZiBe70nv+B7ok6D70=; b=aYzpjfU3y/qp3fqvbNjKoyaw7K60uGnobajmDmSAUoOv9B5JF1RTQVgQSZ1jQ+lKH6 vBQfIs9CE8DSuaci4RRqutNz62mVWagrm5Cws7AkKzaxTjIFPojNB96Ks+deiLAXaHIM Fp0TqHW4tZ2PwCunAyJjkmtbCOFkplw3RYhZzVO+ChsgHuOeBlkDd+W4M4NZpyQrfyBF AKdUgWBFfBLVYf9Ca9i3bUFxweGeHs5VjRYHNR+D3EkbEnKcWUqqIqyqyNNNGOv7V7Fz goVNuIb/pxhhCS8WaMT+IY4nmeqkxwso0QblPHozHjMWP2h32PA7dCWMdagsU6gI9z8C 94ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696999745; x=1697604545; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AffNU6tT3rlGnQ3XqLjFz/EUfJZiBe70nv+B7ok6D70=; b=nPKneYeBOqy52KtbLF2CnRD9xtq3r1oZG+FGqb2iWBTZv/bxR9TeQdWHQdF38IT6fm e/MCOGzWixvNbg8XfgkMhLS4P16bftcqbBRXjWwvLvFmmqVwfgN9PPAtOhY0My0l6Zn0 NCIumqNc41ysH8vSbu5u8LkRQ4xksHPfL3yh/VYDYfKNSD3HVNV+117Feldt0Sa5EqY3 XGt2KY9bqg6AloyThHvPjNr89rSfj/k0Erjd6rHsqwkUx4lMnJyUrgZypg0lXq9Nu7LB kNqIADXr6BssOBLcreibqgJ2d55N1Al8+OUHrBhDrq9PCuNNktfs6SJQMPxPwUNMiN7U bAxQ== X-Gm-Message-State: AOJu0YwHVT0NV6LhUDzLVxMmbuGwJMUlgq5d6wck6APOkmzknFyJwXO7 3zZtdKzkRjI1BcuxLQJ21jLcXRMAGWjPXA== X-Google-Smtp-Source: AGHT+IFpYj1fCh5cavj4iXrFyJGbMytQNYdYHpDjE0znHWOa5BW3ob6WYUBA4Lu9kgIpOJkjcM0w2w== X-Received: by 2002:a05:600c:1e2a:b0:402:ebe1:7960 with SMTP id ay42-20020a05600c1e2a00b00402ebe17960mr14523279wmb.2.1696999744436; Tue, 10 Oct 2023 21:49:04 -0700 (PDT) Received: from [10.24.0.64] ([89.207.171.100]) by smtp.gmail.com with ESMTPSA id y6-20020a1c4b06000000b00405588aa40asm15684431wma.24.2023.10.10.21.49.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Oct 2023 21:49:03 -0700 (PDT) Message-ID: Date: Wed, 11 Oct 2023 06:49:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode To: Iain Sandoe Cc: GCC Development , libstdc++ , GCC Patches References: <4ebb6936-d652-84a5-0028-6ca0a5d2d238@gmail.com> <324ED72B-E687-4B5E-AD6E-C7A3BBDEB223@sandoe.co.uk> Content-Language: en-US From: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= In-Reply-To: <324ED72B-E687-4B5E-AD6E-C7A3BBDEB223@sandoe.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_ABUSEAT,RCVD_IN_DNSWL_NONE,RCVD_IN_SBL_CSS,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 08/10/2023 15:59, Iain Sandoe wrote: > Hi François, > >> On 23 Sep 2023, at 21:10, François Dumont wrote: >> >> I'm eventually fixing those tests the same way we manage this problem in libstdc++ testsuite. >> >> testsuite: Add optional libstdc++ version namespace in expected diagnostic >> >> When libstdc++ is build with --enable-symvers=gnu-versioned-namespace diagnostics are >> showing this namespace, currently __8. >> >> gcc/testsuite/ChangeLog: >> >> * testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add optional >> '__8' version namespace in expected diagnostic. >> * testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise. >> * testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise. >> * testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: Likewise. >> * testsuite/g++.dg/coroutines/pr97438.C: Likewise. >> * testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise. >> >> Tested under Linux x86_64. >> >> I'm contributing to libstdc++ so I already have write access. >> >> Ok to commit ? > As author of the tests, this LGTM as a suitable fix for now (at least, once the main > patch to fix versioned namespaces lands). I just realized it was a "go", no ? Then why after the main patch ? The "main patch" do not fix the versioned namespace. It just makes it adopt the cxx11 abi. This patch fixes a problem that is as old as the tests and that is totally unrelated with the main one. I just wanted to improve the situation so that versioned namespace mode do not look more buggy than necessary when someone (like you) run those. > > However, IMO, this could become quite painful as more g++ tests make use of std headers > (which is not really optional for facilities like this that are tightly-coupled between the FE and > the library). > > For the future, it does seem that a more complete solution might be to introduce a > testsuite-wide definition for the C++ versioned std:: introducer, so that we can update it in one > place as the version changes. > > So (as a thought experiment): > - we’d have something of the form “CXX_STD” as a tcl global > - we’d add the presence/absence of versioning to the relevant site.exp (which > means recognising the versioning choice also in the GCC configure) > - we’d migrate tests to using ${CXX_STD} instead of "std::__N” in matches > > … I guess an alternative could be to cook up some alternate warning/error/etc > match functions that cater for arbitrary inline namespaces but that seems like a much > more tricky and invasive testsuite change. > > thoughts? I considered amending gcc/testsuite/lib/prune.exp to simply remove the version from the diagnostic. But the reply on why it was not working scared me, so this patch. https://gcc.gnu.org/pipermail/gcc/2023-September/242526.html