From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11olkn2075.outbound.protection.outlook.com [40.92.18.75]) by sourceware.org (Postfix) with ESMTPS id 0CEB13858409 for ; Mon, 27 Sep 2021 03:40:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0CEB13858409 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vc57fDk9cdOPsPjwylsFukRw52Te8PfHU0F7iEhBUq9E6OUSlwSQfeBgiX2vbXeBF0UTf3kV/M7iOExFUshSWsa0ieB2447q4ig8vgWB6p3kG9QaNCibAuVv2xR2VEpwGAYcqleikExbx8EoQEzRLEnSCrukdJyJInPSubyo3JofUV96f8Rpf4gNHGePEI1zxDVfjp3jPber3m8XY1JjnMnk5sid/N/DqOH7bWmdYGoborSu5g/+SIvMt8kLQL0yhvOzikLzC/a4ysNkGQyXGVc84W33WHw3bjgi46lFlnYVmZatAjpQHkSBlSA63CO/8pepoPAY228DcXUyD20B6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GzNHv4i3FzmbmT5PlLBdgQr1l8dx+2XgXQsFb2Zy3f4=; b=X55YsLktNoN0pw9oXeg7LF4FItZwAXXBhD5tx0Ft10d3UPMz2bM5wQ2ItVg7KvHQbicRgACzZkJQCIyLMK9si7OtSodgZTLrMkvNEO2D3wmbVhCOdWWVQawx3+GD1/KFVM4z1oS8rljMIgOdbnHTVHnRkRQ7qdBxpjccS9jaxIQ2fvGZqKXumTSejjURgn7DE6f2okamVB4RcH0NVXSlXgjFV+jaMhwtY4CYKH/72+zNc0NoyXprPvNokbm1SYm7+jx3CjXhTzUrjuiSXQLF2Bp52fbF26ZtnGEWmyiJ8xdr9PYhgpsDNM350cMKLLmOneyGQThbATeGYKne93jQTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from MWHPR0501MB3737.namprd05.prod.outlook.com (2603:10b6:301:7a::17) by MW4PR05MB8812.namprd05.prod.outlook.com (2603:10b6:303:12f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.10; Mon, 27 Sep 2021 03:40:50 +0000 Received: from MWHPR0501MB3737.namprd05.prod.outlook.com ([fe80::853a:8f60:a4f0:2ba0]) by MWHPR0501MB3737.namprd05.prod.outlook.com ([fe80::853a:8f60:a4f0:2ba0%4]) with mapi id 15.20.4566.012; Mon, 27 Sep 2021 03:40:50 +0000 From: nick huang To: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044] Thread-Topic: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044] Thread-Index: AQHXnm3npvcE3z86VU61Xh5HS2CgaKuzLUUngACF64CAA6hjSw== Date: Mon, 27 Sep 2021 03:40:49 +0000 Message-ID: References: <5757d35b-3562-5ab8-5062-8ff806d32693@redhat.com> In-Reply-To: <5757d35b-3562-5ab8-5062-8ff806d32693@redhat.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: a13fc58b-cb09-6c20-df66-86fdd38ed4d8 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [vYWv3cMjgP5sHOUvWbvq/rP5x4FTgdbl] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ddaa987a-e6d0-44b1-7ec8-08d981689986 x-ms-traffictypediagnostic: MW4PR05MB8812: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1W+nLI9LNkkKtFUc8w5rhpoo/FitmWiT/ehwlX+yuB4SoM2HJFB4+SJ2ZVCr+oR/GNguAWvyAPFsoDY0T9jpXGqvXl/aSGRMLEXTDcbWXTjru1GyRFb/tAxlB2600sNTlK81haVmw/ztpAA1AkMAZrV9dghPPjZau74mToE6YwFKsrRIYLX75R3xTdNpry6RsqZi/1s4p6bzyQKmDrLSiVWPGBU45IgP48NPc4vqQvteVpytpuvMnMyMHudUIjO3x/340fYJ8TIFfHBXoQbUapE8YWPTVCjtG9gsFdsBToT/8JWWts0ooNzxclmy0qmGOR0IRWGBfKqMqyutIpmETE57Ib6mVZHTiwyAb256osJ7cHcrluuJV/SO4IH9/1ApHMpU1m+s1h1i4GqkJzfI0ubmttCo8bmwpjzc0Mna4VBALKkk49lelgOaMILLolSUDSyZRPBU5CwmT3rC3BifKC7BQwaR608FOij/Z1txPAU= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: YLhPr0qydAOWN6uqm2DE7YWt3ARyBe2VKdJynDmf1RUKbGbxcdgC9bwPSBaqFGDi9LHOWyKZf+Adsg8I3lXYcyWWleiFMUvkzChq5ZX7EhGD8rInb8GYkZfm6EKIp1gA0u6qNUh0ORBLve8B6/0d1w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-8-msonline-outlook-e6bda.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR0501MB3737.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: ddaa987a-e6d0-44b1-7ec8-08d981689986 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2021 03:40:50.1136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR05MB8812 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 03:40:55 -0000 >>template =0A= >>struct A=0A= >>{=0A= >> void f(T);=0A= >>};=0A= >>=0A= >>template =0A= >>void A::f(const T)=0A= >>{ }=0A= >>=0A= >>which is certainly questionable code, but is currently also accepted by = =0A= >>clang and EDG compilers.=0A= =0A= I just found out that clang actually correctly reject this code during spec= ialization. =0A= (https://www.godbolt.org/z/evjvhqqoo)=0A= It all depends on explicit argument which may turn "const" into top-level-c= v-qualifier=0A= or not.=0A= For example, when argument is "int[3]", the function signature of specializ= ation =0A= will have to keep the const because it is no longer top-level cv qualifier.= =0A= =0A= template<>=0A= void A::f(const int*){} // not matching declaration "void(int*)"=0A= =0A= Obviously when explicit argument is "int", the const would be dropped and s= pecialization matches=0A= declaration. i.e.=0A= template<>=0A= void A::f(int){} // this matches declaration "void(int)"=0A= =0A= So, clang is correct to NOT reject template definition when there is no spe= cialization yet.=0A= =0A= As a comparison, GCC is not able to reject incorrect specialization. Shoul= d we file this bug? Or just add this =0A= as test case to original 1001 core issue?=0A= =0A= Again, my patch cannot deal this case as it is not "typename". We may have = to fix "tsubst_function_decl" to see any workaround of line "SET_DECL_IMPLI= CIT_INSTANTIATION (r);" =0A= (See my previous email https://gcc.gnu.org/pipermail/gcc-patches/2021-Septe= mber/580260.html)=0A= This macro "DECL_USE_TEMPLATE" is set to 1. However, the comment says "1" i= s for "implicit specialization", but we are actually dealing with "partial = or explicit specialization" which is "2".=0A= =0A= Here I quote comment from cp-tree.h=0A= =0A= /* Nonzero iff NODE is a specialization of a template. The value=0A= indicates the type of specializations:=0A= =0A= 1=3Dimplicit instantiation=0A= =0A= 2=3Dpartial or explicit specialization, e.g.:=0A= =0A= template <> int min (int, int),=0A= =0A= 3=3Dexplicit instantiation, e.g.:=0A= =0A= template int min (int, int);=0A= =0A= Note that NODE will be marked as a specialization even if the=0A= template it is instantiating is not a primary template. For=0A= example, given:=0A= =0A= template struct O {=0A= void f();=0A= struct I {};=0A= };=0A= =0A= both O::f and O::I will be marked as instantiations.=0A= =0A= If DECL_USE_TEMPLATE is nonzero, then DECL_TEMPLATE_INFO will also=0A= be non-NULL. */=0A= =0A=