From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by sourceware.org (Postfix) with ESMTPS id AA0A13858C5E for ; Tue, 7 Nov 2023 14:45:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AA0A13858C5E 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 AA0A13858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699368319; cv=none; b=FaT3c+OJYbBSpxFI1wP2plpT5pzmFUivk167hPeAQCp3S1Kn4MomL+j3wxuxAZPrzNk2GOfEHUBbe0eWaCYb52smq6AzfvB0/8wTOC8TOOpE9MSiZ1f9BCTPK006qYpZOzNpciPcxGJhBQPIVTZGKtmg1iNXk4JOz3Ptrt3Yx3s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699368319; c=relaxed/simple; bh=McabPZTTtMDXA6SF4pt+ik0ZoRzkjhiv/rTEc4st6z0=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=IjvAqGBG9f53dE2euSNXkEG2YchDhf8hOgIBgzOvoGTaRErtWH2AR7BfAHyqEJxpG7dWtNX+GCxuqQmok5jkY6YWb0yjRRNF3YrahJg3DYog5XVuU6FaSOCFNXrV0uET9Nb/iWRqCU3Nn4FlQyA/V+RiIrNI3nmmTBMxDtr3mK0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1699368315; x=1699627515; bh=JPLHTpzQJJHqkSMvhPmmEzHubhUgfihP2TW4vtTvAts=; 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=N/uhURhGxmP0eoLLpsQ2NRqi/Gd/zAHewPnTWAPP/17MXX/6VfqUc0dwhXOaJi4bJ HdU+5/ZKc05cL5z2TrzcdlIv1lA7GKZ4nGXuFRNHp9DlsuWtqx+DxEMLa75NRKmCxy b7wqRqDtOu4XfoLUrWhYdoL6LIH9IetayAH3ryl/aE2bFgqoIVEyd4HvL2hfLjcAB3 r0b2zC79a0EWNlZ4GyRK79nHLYbHzwanlDUXJIgScq1Kn3EcIdXScaa59GIIXYahvL 02tmrkEHrtNjOQ5nhCzZIhbcoaR2H4aOsOasy1H6/p7irCR0we0bSlVKB/wbY4aAvc mKosGMQrCp+fA== Date: Tue, 07 Nov 2023 14:45:05 +0000 To: waffl3x From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v4 1/2] c++: Initial support for P0847R7 (Deducing this) [PR102609] Message-ID: In-Reply-To: <7N-k8O0zfePgSAEbzdPO3eGBPJA0Yrg__iRbGQKl9EM2tMwZyckQHLqoS010EALNhrwO41zYqmFfGkbNIk6edrFZCwNY9c4WOjq7z6mUABw=@protonmail.com> References: <7N-k8O0zfePgSAEbzdPO3eGBPJA0Yrg__iRbGQKl9EM2tMwZyckQHLqoS010EALNhrwO41zYqmFfGkbNIk6edrFZCwNY9c4WOjq7z6mUABw=@protonmail.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=-1.9 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,TO_EQ_FM_DIRECT_MX,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: I guess I'll be attaching all new e-mails here. I found a new, kinda scary issue. ``` bool start_preparsed_function (tree decl1, tree attrs, int flags) { tree ctype =3D NULL_TREE; bool doing_friend =3D false; /* Sanity check. */ gcc_assert (VOID_TYPE_P (TREE_VALUE (void_list_node))); gcc_assert (TREE_CHAIN (void_list_node) =3D=3D NULL_TREE); tree fntype =3D TREE_TYPE (decl1); if (TREE_CODE (fntype) =3D=3D METHOD_TYPE) ctype =3D TYPE_METHOD_BASETYPE (fntype); else if (DECL_XOBJ_MEMBER_FUNC_P (decl1)) ctype =3D DECL_CONTEXT (decl1); ``` ``` if (ctype && !doing_friend && !DECL_STATIC_FUNCTION_P (decl1)) { /* We know that this was set up by `grokclassfn'. We do not wait until `store_parm_decls', since evil parse errors may never get us to that point. Here we keep the consistency between `current_class_type' and `current_class_ptr'. */ tree t =3D DECL_ARGUMENTS (decl1); gcc_assert (t !=3D NULL_TREE && TREE_CODE (t) =3D=3D PARM_DECL); gcc_assert (TYPE_PTR_P (TREE_TYPE (t)) || DECL_XOBJ_MEMBER_FUNC_P (decl1)); cp_function_chain->x_current_class_ref =3D cp_build_fold_indirect_ref (t); /* Set this second to avoid shortcut in cp_build_indirect_ref. */ cp_function_chain->x_current_class_ptr =3D t; /* Constructors and destructors need to know whether they're "in charge" of initializing virtual base classes. */ /* SNIP IRRELEVANT */ } ``` I made changes in this function, which suddenly sent execution into the second code block. It seems like this would have been being bypassed until the fix at the top of the function. Initially this was to fix a problem with lambdas, but suddenly a lot of other stuff seems to be breaking. I haven't run the tests yet but... I have a really bad feeling about this. So my concerns here are, one, this seems kind of important upon looking at it, what kind of stuff might have been broken when this was being bypassed that I didn't notice? And two, how in the world was it working when this was being bypassed? I have a hunch that some of the reinterpretation and "just works" behavior might have had something to do with this block of code being bypassed. I also suspect that this area will need some changes to make by-value xobj parameters work. However, I'm a little confused at why this block is necessary at all. Like I have noted before, when attempting to call a by-value xobj member function, if there are no viable conversions, the call will fail. So it's checking for that somewhere. normal.C: In explicit object member function 'uintptr_t S::f(this uintptr_t= )': normal.C:15:33: error: invalid type argument (have 'uintptr_t' {aka 'long u= nsigned int'}) 15 | uintptr_t f(this uintptr_t n) { | ^ normal.C: In explicit object member function 'uintptr_t S::g(this FromS)': normal.C:18:34: error: invalid type argument (have 'FromS') 18 | uintptr_t g(this FromS from_s) { | ^ But now that we are entering this code block, (when compiling explicit-obj-by-value2.C) these errors are popping up. Why now? Why isn't this being handled in the same place other things are? How important is this block of code really? Is this the origin of the weird errors where rvalue refs are being accepted for functions that take const rvalue refs? Is this code just setting up the 'this' pointer? I have so many guesses and so many questions. I don't think I can just bypass it though, but maybe I can? This is another one that feels really deep down the rabbit hole so I would appreciate any insight that can be provided. Anyway, I had thought that I probably just need to change how build_over_call works to get passing to by-value xobj params to work. But now that I've found this code and gotten these new errors to surprise me, now I'm a little worried. If it's just for the 'this' pointer then it's probably fine. I need to sleep now, I hadn't planned on looking at this for as long as I did but I got sucked in. I think tomorrow I will go back to bypassing this code block and try to make changes to build_over_call works and see if that does the trick. But things feel all over the place now so I'm a little concerned about what else I might be neglecting. Thanks, Alex