From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5840238845AF for ; Wed, 29 Nov 2023 22:00:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5840238845AF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5840238845AF Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701295203; cv=none; b=w6oNowl05cNBwtuZHaDLvkHalo5JN/uxAUAfp6c5wWywh65qkfx1y5eUMh1E59swS1BGSAhHBcj5eG60oC8QH8rIoYAMtxbHOkXJ0lrFi22HH0euEPLbae1yUS4P5oEXKPE/6mz/4+kyYMYHDn6egGioHauHDb87LTg1RU+NEyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701295203; c=relaxed/simple; bh=Aw7XNXxFu+qD5rAkjeOMU62fQXpWvZCmgAiIQtZsT5s=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=aDp58h5ILs7i4YhIPiECrAabe04iz7qIhGdyFogbkRkjmGCeoS3Krn68k/O6vXVTwcE5atQQzAWWZpniGdCVRpjv4iDozQ2C1VDjTWHJQjgI/M/SavmX+UUIUVqzI/0mRIJ3jyTfAgNSRcC3+6PJlE4LW0NibS3CpR/B8ToxE7Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701295201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JRmgDth5jk8f4s/gr4mRQsYWRmOmUTsj0C2EKDB7bNw=; b=cWxgA632kY1baOpIdiKDXAr84HPHwoMnPXnzbNvaAV3Itz60lajEOu2Sn+1yBz8ip9MKao zVhcxe9y0wDDXBcBbcvyHiCwUSz9YhWtbicz6VmMWL+jQzR7aaFuoI5EUSCoaDTwPaDLut 6Q93bnXdTx/X1vqGLGTJ/H+fD2rHPNI= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-sGKlgDLhNICFJaIJY1hI7Q-1; Wed, 29 Nov 2023 17:00:00 -0500 X-MC-Unique: sGKlgDLhNICFJaIJY1hI7Q-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-77d85fd2ca8so286320985a.0 for ; Wed, 29 Nov 2023 14:00:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701295200; x=1701900000; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JRmgDth5jk8f4s/gr4mRQsYWRmOmUTsj0C2EKDB7bNw=; b=dhkDepCCNeA/Yxi1sSSypmfyDFE/P5XcHbmNSiwt29XH5z8hknowlWzQfGO1qhyWIf dXH5sbRfu0LhurtHhm6wsUbJgrubOMQRYa1u9liFjKK1vJgm5Bu3odIciz3KBFYx/hwi coc9a1+TmOJB/9lIz61aR59258nqYqGIZ6r1ImdY4RA1SWlSYzJZW9Fo5goyzuyBN8lf bMfNWBAvHccw4RPBeELZf/1GRFp89tJuXR7P7B7fagxtzqWysDWG0J2UcvTfVFwYcSDU e2mCNPrR0x0orWByCwJOufrA0/lzBQpjlRWwewgcykD1l0NbaG1493OBpfSve6kVRhBc bpCg== X-Gm-Message-State: AOJu0Yyw3pSc6ALheFYpk0JoWKtdgZBF4AQf3WLBiIIbcGdsSiJ+Gqk1 IKLgLULmyEViPL+8O93p7hu6uHmMJ0zL1EOdaJ7mR/ufBVwBT9wA2v7WkaEM6qUvg008UwATXBG Dw16RCKEaJiQHvKdqBJ8mxDkt8A== X-Received: by 2002:a05:620a:27d5:b0:76f:5b9:3f29 with SMTP id i21-20020a05620a27d500b0076f05b93f29mr34315842qkp.2.1701295199828; Wed, 29 Nov 2023 13:59:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IG7g/ZxHYohJAwT6xNQ5//qVLq5c6EA+6zqFtJ8qzXqQVuKScAjvdlQoY6c8PztfPG2MLhNSQ== X-Received: by 2002:a05:620a:27d5:b0:76f:5b9:3f29 with SMTP id i21-20020a05620a27d500b0076f05b93f29mr34315816qkp.2.1701295199560; Wed, 29 Nov 2023 13:59:59 -0800 (PST) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id pb27-20020a05620a839b00b0077dc299f44esm1528867qkn.51.2023.11.29.13.59.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 13:59:59 -0800 (PST) Date: Wed, 29 Nov 2023 16:59:57 -0500 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: wrong ambiguity in accessing static field [PR112744] Message-ID: References: <20231129154512.428173-1-polacek@redhat.com> <80a8828a-2abc-478d-b65a-fcb631ca45fd@redhat.com> MIME-Version: 1.0 In-Reply-To: <80a8828a-2abc-478d-b65a-fcb631ca45fd@redhat.com> User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Wed, Nov 29, 2023 at 01:58:31PM -0500, Jason Merrill wrote: > On 11/29/23 10:45, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > Now that I'm posting this patch, I think you'll probably want me to use > > ba_any unconditionally. That works too; g++.dg/tc1/dr52.C just needs > > a trivial testsuite tweak: > > 'C' is not an accessible base of 'X' > > v. > > 'C' is an inaccessible base of 'X' > > We should probably unify those messages... > > Hmm, won't using ba_any unconditionally break ambiguous base checking for > non-static data members? Yes. I thought not but that's only because we weren't properly testing that case (added scoped14.C, patch to follow). So that settles that. > > @@ -3493,9 +3493,24 @@ finish_class_member_access_expr (cp_expr object, tree name, bool template_p, > > return error_mark_node; > > } > > + /* NAME may refer to a static data member, in which case there is > > + one copy of the data member that is shared by all the objects of > > + the class. So NAME can be unambiguously referred to even if > > + there are multiple indirect base classes containing NAME. */ > > + const base_access ba = [scope, name] () > > Why a lambda? Only so that I can set 'ba' once and make it const. I don't believe it deserves a named function. It seems more readable than using a ?:. > > + { > > + if (identifier_p (name)) > > + { > > + tree m = lookup_member (scope, name, /*protect=*/0, > > + /*want_type=*/false, tf_none); > > + if (!m || VAR_P (m)) > > Do you want shared_member_p here? That looks like the right thing to use, thanks. Marek