From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by sourceware.org (Postfix) with ESMTPS id 8A39A3858416 for ; Thu, 19 Oct 2023 23:35:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A39A3858416 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8A39A3858416 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697758549; cv=none; b=BN8g7NlEPdZxVVi+yoxU8/pmTNwXY6v31kpkfRQkJWkUDFc4ykG/YTJ5/bL3oAxe37L7EnyOFooVbLmT5rpifJENDC+VSu34eQ1udH3TEmbsFi0A2XoGDS259ObCcnx3OZzL7v3W8OGTZyABbzEl/uIVFVBfHBLob/tfGKwuWFY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697758549; c=relaxed/simple; bh=x3HZdz7WPgWWKPP1pqlEvvsDr/MCg8MYwpQzZxIDJTA=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=fxgJTQlWyFc5jn2nDJ8ROrhZlK4zKmDivLuJEpx1XNFP0fiWkKjmexRXm/rv4u4kwYUnsGMx7zhfkC9kksFH9vsdHJsM856vvChm06RanxnOkHdSfT+3u2fctcHY4tyqpTg1Bav6XNWPUKB5zF8NTp12ZG3nI095GnWTr0V/TMg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1697758542; x=1698017742; bh=x3HZdz7WPgWWKPP1pqlEvvsDr/MCg8MYwpQzZxIDJTA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=O/0IZ2furFbwy5UhHb7oNTvHW/jE3zRzb18FOrydOfcmX1Fdp6uH9OKMHS2drhgOc oHZ0pdbJXwx/gO7QGXmHb7F9/10iCu9SpPgMc9SjI9rxubkqVV1iTJaa6o53gAAPkh sEXnrwlTqiJwRnNrxJ1vrqJGSjlk64/qz1fz7Oox/oMzM2DlfevLgeL4ltfcbgSnuE plbVz7hTZpnGu4U8fU11JPRDhIWXe0YSC1IwWMO/XkmHZBCFcqDuynsuXkzWs3leb0 Z7rfiZ6dusRWH4eqhxATgqBSJrleGwcFGv+JNzIgDMcxARdNjbYx779LUazFpbhPMt gE+VH1pPx4a5A== Date: Thu, 19 Oct 2023 23:35:36 +0000 To: Jason Merrill From: waffl3x Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <0cc5b21d-4b27-4964-bec3-544c86307c74@redhat.com> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: > (waffl3x (me)) > At a glance it seems like all I need to do then is disable the > PTRMEM_OK_P flag then. I'm just now realizing that I'm almost certainly wrong about this. It still needs PTRMEM_OK_P set if there are any implicit-object member functions in the overload set. That is, if OFFSET_REF includes that information... but it doesn't seem like it does? Reading the information on OFFSET_REF, particularly build_offset_ref, seems to indicate that OFFSET_REF (at least historically) was only for things with a pointer to member type. > > An OFFSET_REF (with PTRMEM_OK_P) is used to express that we saw the > > &A::f syntax, so we could build a pointer to member if it resolves to a= n > > implicit-object member function. > >=20 > > For an overload set containing only a single static member function, > > build_offset_ref doesn't bother to build an OFFSET_REF, but returns the > > BASELINK itself. Based on what you've said, I assume that OFFSET_REF handles static member functions that are overloaded. But as I've said this seems to contradict the comments I'm reading, so I'm not sure that I'm understanding you correctly. I suppose that will be pretty easy to test, so I'll just do that as well. > > I think we need the OFFSET_REF for an explicit-object member function > > because it expresses that the code satisfies the requirement "If the > > operand names an explicit object member function, the operand shall be = a > > qualified-id." I do agree here, but it does reinforce that OFFSET_REF is no longer just for members represented by pointer to member type. So that might be something to take into consideration. > > It might simplify things to remove the optimization in build_offset_ref > > so we get an OFFSET_REF even for a single static member function, and > > add support for that to cp_build_addr_expr_1. I don't think this should be necessary, the "right thing" should just be done for explicit-object member functions. With all the stuff going on here that I missed I'm starting to wonder how function overloads ever worked at all in my patch. On the other hand though, this optimization probably could be documented better, but I very well might have missed it even if it were. Hell, maybe it needs a greater redesign altogether, it seems strange to me to bundle overload information in with a construct for a specific expression. (Assuming that's whats happening of course, I still don't fully understand it.) It's not like this has rules unique to it for how overload resolution is decided, right? Initializing a param/variable of pointer to function type with an overloaded function resolves that with similar rules, I think? Maybe it is a little different now that I write it out loud. I wasn't going to finish my musings about that, but it made me realize that it might not actually be correct for address of explicit-object member functions to be wrapped by OFFSET_REF. I mean surely it's fine because based on what you've said static member functions are also wrapped by OFFSET_REF, so it's likely fully implemented, especially considering things worked before. But now that there are 2 different varieties of class members that the address of them can be taken, it might make sense to split things up a bit? Then again, why were static member functions ever handled the same way? Taking the address of other static members isn't handled in the same way here is it? I'm probably spending too much time thinking about it when I don't fully understand how it's all being done, I'll just go back to poking around trying to figure it all out. Then I'll worry about whether thing's should be done differently or not. Alex