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 6BFD83858D33 for ; Thu, 9 Nov 2023 21:53:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BFD83858D33 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 6BFD83858D33 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=1699566802; cv=none; b=pZhf63EzSq6OycBoETQVYgGdSuXAwRR7ROV7jLFOj8AWg7dz2sQrxH8DblHLCW0HqrbRPoM8V6D6H6ljrkTMoDQkIwh07CYZ3itTmoJ5BQEySlm/TeEasLf7qupr2keILmfq/yc0kBbTQue/oQICjG1wVJe4i3rqqyTzGpfjZEA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699566802; c=relaxed/simple; bh=EHY06NJ9PWpDrvJHTiHRvSYldv9Y0iojYgx0V9QbN44=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=wwY9O9kv45AEsNIrSidM/H5Dbd6DOnKeFUSCfPYtlVfBXBOX6PKNJ6/H7/mYsMkG67EWCMsG48Di4oD+fS1eakycFV8KRTzgQt9i0Jcfyy/mEGnmOiOZi9hM+uGhHMImx8ICwWWsGKgA/5JPpPqFrmd2ORy14AMNRJ4Ei+5nYvA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699566800; 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=UlJ39L/mNCTp5poNknZC4sxr2pQifJMnOFltv51+LIY=; b=iLNHLsTdIGaf4KPfljKXcGBwuOgojM1Xb+8sgcUdwIKYp1ma6Nnx3YYoI/SQ/t04IP0a/S HaP5F1GaiukRnv3KK65/NGcAkFjU5owbgxivNXsxPSJwjOMBl3DtEzwfmgzYPN+awfp5YF qUgUHk7mPho7W87uhZO5PpSLlif8+/4= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-60-caaufPmqN-Gy6tczyMOAcw-1; Thu, 09 Nov 2023 16:53:18 -0500 X-MC-Unique: caaufPmqN-Gy6tczyMOAcw-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-7788fa5f1b0so145410485a.2 for ; Thu, 09 Nov 2023 13:53:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699566798; x=1700171598; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qv3OtWbuCb7Cr68QujsFl1O8pQvTSHolapMcYDbpFHM=; b=RP5lRcGPmAoVek39teVoLYa4PFhEPPECTf52ukXsq5veS4heVvsCl/3t7xKXvIHgCv J6PRHTod+RPTumf7m/G4ArQJhvHs89S3YTzmXg6Hq74TSG+hyCjDRUuTtttAaLu8qDKP JgDvT0247SEWKzM5ezxSJrC+bO23EFy1sxjWhT0TclLJk5CwHRxJMFZNHlaxL9E3CuAi uN3RCDH+VorORz8Q7hSVk77oeDQaoojeeMPStEhPD+HjLoXP7AdNMbWXv1yBPoPCRXOa UbJ2rjuHrSfEi/5CSNFIAZnj5kqkitxkt/ukKaOcxs9yJ9y4GTzQHc/IKzD0J5Jyaebn f2+A== X-Gm-Message-State: AOJu0YyUYewSRhOA6Vp7G53L7exJgy7oS90MjXgqf9gTgGWq/TbXOU7X K++ENKnV9qeFydDWJo8ChMsUOk4WmvoPi3+KfFPYZBSBYx3XYSc0Rp9bleQ+RTWkPVt6P/nrB/S XSNten3vKL9uW6Eik+A== X-Received: by 2002:a05:620a:c46:b0:77a:7e91:45e7 with SMTP id u6-20020a05620a0c4600b0077a7e9145e7mr6744144qki.34.1699566797705; Thu, 09 Nov 2023 13:53:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IHwwJ3KV56ox+ZIb0pW7DTR5fCpDzkHr/+E3jLKzcKMAS0ntgdA03l4w+NYHp5OgNvt0iqJqg== X-Received: by 2002:a05:620a:c46:b0:77a:7e91:45e7 with SMTP id u6-20020a05620a0c4600b0077a7e9145e7mr6744132qki.34.1699566797336; Thu, 09 Nov 2023 13:53:17 -0800 (PST) Received: from [192.168.1.108] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id t3-20020a05620a034300b00775ab978009sm226036qkm.36.2023.11.09.13.53.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Nov 2023 13:53:16 -0800 (PST) Message-ID: <620d6a42-b229-45b4-892b-aee6e9a8d3d7@redhat.com> Date: Thu, 9 Nov 2023 16:53:15 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] c++: Initial support for P0847R7 (Deducing this) [PR102609] To: waffl3x Cc: "gcc-patches@gcc.gnu.org" References: From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------hhWcRoWZeXUP7g4VDJsQKvtB" Content-Language: en-US X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: This is a multi-part message in MIME format. --------------hhWcRoWZeXUP7g4VDJsQKvtB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/5/23 10:06, waffl3x wrote: > Bootstrapped and tested on x86_64-linux with no regressions. > > I originally threw this e-mail together last night, but threw in the > towel when I thought I saw tests failing and went to sleep. I did a > proper bootstrap and comparison and whatnot and found that there were > thankfully no regressions. > > Anyhow, the first patch feels ready for trunk, the second needs at > least one review, I'll write more on that in the second e-mail though. > I put quite a lot into the commit message, in hindsight I think I may > have gone overboard, but that isn't something I'm going to rewrite at > the moment. I really want to get these patches up for review so they > can be finalized. > > I'm also including my usual musings on things that came up as I was > polishing off the patches. I reckon some of them aren't all that > important right now but I would rather toss them in here than forget > about them. > > I'm starting to think that we should have a general macro that > indicates whether an implicit object argument should be passed in the > call. It might be more clear than what is currently present. I've also > noticed that there's a fair amount of places where instead of using > DECL_NONSTATIC_MEMBER_FUNCTION_P the code checks if tree_code of the > type is a METHOD_TYPE, which is exactly what the aforementioned macro > does. Agreed. > In build_min_non_dep_op_overload I reversed the branches of a condition > because it made more sense with METHOD_TYPE first so it doesn't have to > take xobj member functions into account on both branches. I am slightly > concerned that flipping the branch around might have consequences, > hence why I am mentioning it. Realistically I think it's probably fine > though. Agreed. > BTW let me know if there's anything you would prefer to be done > differently in the changelog, I am still having trouble writing them > and I'm usually uncertain if I'm writing them properly. > (DECL_FUNCTION_XOBJ_FLAG): Define. This is usually "New macro" or just "New". > * decl.cc (grokfndecl): New param XOBJ_FUNC_P, for xobj member > functions set DECL_FUNCTION_XOBJ_FLAG and don't set > DECL_STATIC_FUNCTION_P. > (grokdeclarator): Check for xobj param, clear it's purpose and set > is_xobj_member_function if it is present. When flag set, don't change > type to METHOD_TYPE, keep it as FUNCTION_TYPE. > Adjust call to grokfndecl, pass is_xobj_member_function. These could be less verbose; for grokfndecl it makes sense to mention the new parameter, but otherwise just saying "handle explicit object member functions" is enough. > It needs to be noted that we can not add checking for xobj member functions to > DECL_NONSTATIC_MEMBER_FUNCTION_P as it is used in cp-objcp-common.cc. While it > most likely would be fine, it's possible it could have unintended effects. In > light of this, we will most likely need to do some refactoring, possibly > renaming and replacing it. In contrast, DECL_FUNCTION_MEMBER_P is not used > outside of C++ code, so we can add checking for xobj member functions to it > without any concerns. I think DECL_NONSTATIC_MEMBER_FUNCTION_P should probably be renamed to DECL_IOBJ_MEMBER_FUNC_P to parallel the new macro... > @@ -3660,6 +3660,7 @@ build_min_non_dep_op_overload (enum tree_code op, > > expected_nargs = cp_tree_code_length (op); > if (TREE_CODE (TREE_TYPE (overload)) == METHOD_TYPE > + || DECL_XOBJ_MEMBER_FUNC_P (overload) ...and then the combination should have its own macro, perhaps DECL_OBJECT_MEMBER_FUNC_P, spelling out OBJECT to avoid visual confusion with either IOBJ/XOBJ. Renaming the old macro doesn't need to happen in this patch, but adding the new macro should. > There are a few known issues still present in this patch. Most importantly, > the implicit object argument fails to convert when passed to by-value xobj > parameters. This occurs both for xobj parameters that match the argument type > and xobj parameters that are unrelated to the object type, but have valid > conversions available. This behavior can be observed in the > explicit-obj-by-value[1-3].C tests. The implicit object argument appears to be > simply reinterpreted instead of any conversion applied. This is elaborated on > in the test cases. Yes, that's because of: > @@ -9949,7 +9951,8 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain) > } > } > /* Bypass access control for 'this' parameter. */ > - else if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE) > + else if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE > + || DECL_XOBJ_MEMBER_FUNC_P (fn)) We don't want to take this path for xob fns. Instead I think we need to change the existing: > gcc_assert (first_arg == NULL_TREE); to assert that if first_arg is non-null, we're dealing with an xob fn, and then go ahead and do the same conversion as the loop body on first_arg. > Despite this, calls where there is no valid conversion > available are correctly rejected, which I find surprising. The > explicit-obj-by-value4.C testcase demonstrates this odd but correct behavior. Yes, because checking for conversions is handled elsewhere. > Other than this, lambdas are not yet supported, The error I'm seeing with the lambda testcase is "explicit object member function cannot have cv-qualifier". To avoid that, in cp_parser_lambda_declarator_opt you need to set quals to TYPE_UNQUALIFIED around where we do that for mutable lambdas. > and there is some outstanding > odd behavior where invalid calls to operators are improperly accepted. The > test for this utilizes requires expressions to operate though so it's possible > that the problems originate from there, but I have a hunch they aren't > responsible. See explicit-obj-ops-requires-mem.C and > explicit-obj-ops-requires-non-mem.C for those tests. I think that's the same issue as by-value1.C above. Though you're also missing a couple of semicolons on > + RRef&& operator()(this RRef&& self) { return static_cast(self) } > + RRef&& operator[](this RRef&& self) { return static_cast(self) } > @@ -7164,6 +7164,12 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue, tsubst_flags_t complain) > && !mark_used (t, complain) && !(complain & tf_error)) > return error_mark_node; > > + /* Exception for non-overloaded explicit object member function. > + I am pretty sure this is not perfect, I think we aren't > + handling some constexpr stuff, but I am leaving it for now. */ > + if (TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE) > + return build_address (t); Specifically, you're missing the SET_EXPR_LOCATION at the end of the function. Maybe break here instead of returning? > +// missing test for three-way-compare (I don't know how to write it) > +// missing test for ->* (I don't know how to write it) Following the same pattern seems to work for me, e.g. (OPERAND) <=> 0 and (OPERAND) ->* 0. > +template > +void do_calls() You probably want to instantiate the templates in these testcases to make sure that works. > +// It's very hard to test for incorrect successes without requires, and by extension a non dependent variable > +// so for the time being, there are no non dependent tests invalid calls. I don't understand the problem, you can have requires-expressions in non-dependent context. Jason --------------hhWcRoWZeXUP7g4VDJsQKvtB Content-Type: text/x-patch; charset=UTF-8; name="0001-gcc-testsuite-ChangeLog.patch" Content-Disposition: attachment; filename="0001-gcc-testsuite-ChangeLog.patch" Content-Transfer-Encoding: base64 RnJvbSAwN2IwMDdhNDRhMjc3ZjdiNWNkZTY5ZjVlNTRjMmJlMzM2ZGZjYTFiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKYXNvbiBNZXJyaWxsIDxqYXNvbkByZWRoYXQuY29tPgpEYXRl OiBUaHUsIDkgTm92IDIwMjMgMTY6MzQ6NTUgLTA1MDAKU3ViamVjdDogW1BBVENIXSBnY2MvdGVz dHN1aXRlL0NoYW5nZUxvZzoKVG86IGdjYy1wYXRjaGVzQGdjYy5nbnUub3JnCgoJKiBnKysuZGcv Y3BwMjMvZXhwbGljaXQtb2JqLW9wcy1ub24tbWVtLmg6IEFkZCA8PT4gYW5kIC0+Ki4KLS0tCiAu Li4vZysrLmRnL2NwcDIzL2V4cGxpY2l0LW9iai1vcHMtbm9uLW1lbS5oICAgICAgICAgfCAxMyAr KysrKysrKystLS0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL2djYy90ZXN0c3VpdGUvZysrLmRnL2NwcDIzL2V4cGxpY2l0LW9i ai1vcHMtbm9uLW1lbS5oIGIvZ2NjL3Rlc3RzdWl0ZS9nKysuZGcvY3BwMjMvZXhwbGljaXQtb2Jq LW9wcy1ub24tbWVtLmgKaW5kZXggYjk0ZTU2YjFkZDYuLjJhOGQ0NmVkMmM2IDEwMDY0NAotLS0g YS9nY2MvdGVzdHN1aXRlL2crKy5kZy9jcHAyMy9leHBsaWNpdC1vYmotb3BzLW5vbi1tZW0uaAor KysgYi9nY2MvdGVzdHN1aXRlL2crKy5kZy9jcHAyMy9leHBsaWNpdC1vYmotb3BzLW5vbi1tZW0u aApAQCAtMSw5ICsxLDYgQEAKLS8vIG1pc3NpbmcgdGVzdCBmb3IgdGhyZWUtd2F5LWNvbXBhcmUg KEkgZG9uJ3Qga25vdyBob3cgdG8gd3JpdGUgaXQpCi0vLyBtaXNzaW5nIHRlc3QgZm9yIC0+KiAo SSBkb24ndCBrbm93IGhvdyB0byB3cml0ZSBpdCkKLQogLy8gdGVzdHMgZm9yIG9wcyB0aGF0IG11 c3QgYmUgbWVtYmVyIGZ1bmN0aW9ucyBhcmUgc2VwZXJhdGUKIAotI2RlZmluZSBNQUtFX1NUUlVD VF9PUFMoVFlQRSkgXAorI2RlZmluZSBNQUtFX1NUUlVDVF9PUFMoVFlQRSkJCQkJCVwKICAgVFlQ RSBvcGVyYXRvcis9KHRoaXMgVFlQRSBzZWxmLCBpbnQpIHsgcmV0dXJuIHNlbGY7IH0JCVwKICAg VFlQRSBvcGVyYXRvci09KHRoaXMgVFlQRSBzZWxmLCBpbnQpIHsgcmV0dXJuIHNlbGY7IH0JCVwK ICAgVFlQRSBvcGVyYXRvcio9KHRoaXMgVFlQRSBzZWxmLCBpbnQpIHsgcmV0dXJuIHNlbGY7IH0J CVwKQEAgLTM5LDcgKzM2LDkgQEAKICAgVFlQRSBvcGVyYXRvcj4odGhpcyBUWVBFIHNlbGYsIGlu dCkgeyByZXR1cm4gc2VsZjsgfQkJXAogICBUWVBFIG9wZXJhdG9yPD0odGhpcyBUWVBFIHNlbGYs IGludCkgeyByZXR1cm4gc2VsZjsgfQkJXAogICBUWVBFIG9wZXJhdG9yPj0odGhpcyBUWVBFIHNl bGYsIGludCkgeyByZXR1cm4gc2VsZjsgfQkJXAorICBUWVBFIG9wZXJhdG9yPD0+KHRoaXMgVFlQ RSBzZWxmLCBpbnQpIHsgcmV0dXJuIHNlbGY7IH0gXAogICBUWVBFIG9wZXJhdG9yKih0aGlzIFRZ UEUgc2VsZikgeyByZXR1cm4gc2VsZjsgfQkJXAorICBUWVBFIG9wZXJhdG9yLT4qKHRoaXMgVFlQ RSBzZWxmLCBpbnQpIHsgcmV0dXJuIHNlbGY7IH0JXAogICBUWVBFIG9wZXJhdG9yJih0aGlzIFRZ UEUgc2VsZikgeyByZXR1cm4gc2VsZjsgfQkJXAogICBUWVBFIG9wZXJhdG9yLCh0aGlzIFRZUEUg c2VsZiwgaW50KSB7IHJldHVybiBzZWxmOyB9CiAKQEAgLTEwNSw4ICsxMDQsMTAgQEAgc3RydWN0 IERlZHVjZWQgewogICB0ZW1wbGF0ZTx0eXBlbmFtZSBTZWxmPiBTZWxmJiYgb3BlcmF0b3I+KHRo aXMgU2VsZiYmIHNlbGYsIGludCkgeyByZXR1cm4gc3RhdGljX2Nhc3Q8U2VsZiYmPihzZWxmKTsg fQogICB0ZW1wbGF0ZTx0eXBlbmFtZSBTZWxmPiBTZWxmJiYgb3BlcmF0b3I8PSh0aGlzIFNlbGYm JiBzZWxmLCBpbnQpIHsgcmV0dXJuIHN0YXRpY19jYXN0PFNlbGYmJj4oc2VsZik7IH0KICAgdGVt cGxhdGU8dHlwZW5hbWUgU2VsZj4gU2VsZiYmIG9wZXJhdG9yPj0odGhpcyBTZWxmJiYgc2VsZiwg aW50KSB7IHJldHVybiBzdGF0aWNfY2FzdDxTZWxmJiY+KHNlbGYpOyB9CisgIHRlbXBsYXRlPHR5 cGVuYW1lIFNlbGY+IFNlbGYmJiBvcGVyYXRvcjw9Pih0aGlzIFNlbGYmJiBzZWxmLCBpbnQpIHsg cmV0dXJuIHN0YXRpY19jYXN0PFNlbGYmJj4oc2VsZik7IH0KIAogICB0ZW1wbGF0ZTx0eXBlbmFt ZSBTZWxmPiBTZWxmJiYgb3BlcmF0b3IqKHRoaXMgU2VsZiYmIHNlbGYpIHsgcmV0dXJuIHN0YXRp Y19jYXN0PFNlbGYmJj4oc2VsZik7IH0KKyAgdGVtcGxhdGU8dHlwZW5hbWUgU2VsZj4gU2VsZiYm IG9wZXJhdG9yLT4qKHRoaXMgU2VsZiYmIHNlbGYsIGludCkgeyByZXR1cm4gc3RhdGljX2Nhc3Q8 U2VsZiYmPihzZWxmKTsgfQogICB0ZW1wbGF0ZTx0eXBlbmFtZSBTZWxmPiBTZWxmJiYgb3BlcmF0 b3ImKHRoaXMgU2VsZiYmIHNlbGYpIHsgcmV0dXJuIHN0YXRpY19jYXN0PFNlbGYmJj4oc2VsZik7 IH0KICAgdGVtcGxhdGU8dHlwZW5hbWUgU2VsZj4gU2VsZiYmIG9wZXJhdG9yLCh0aGlzIFNlbGYm JiBzZWxmLCBpbnQpIHsgcmV0dXJuIHN0YXRpY19jYXN0PFNlbGYmJj4oc2VsZik7IH0KIH07CkBA IC0xNTEsOCArMTUyLDEwIEBAIHN0cnVjdCBEZWR1Y2VkIHsKICAgKE9QRVJBTkQpID4gMDsJXAog ICAoT1BFUkFORCkgPD0gMDsJXAogICAoT1BFUkFORCkgPj0gMDsJXAorICAoT1BFUkFORCkgPD0+ IDA7ICAgICAgXAogCQkJXAogICAqKE9QRVJBTkQpOwkJXAorICAoT1BFUkFORCkgLT4qIDA7ICAg ICAgIFwKICAgJihPUEVSQU5EKTsJCVwKICAgKE9QRVJBTkQpLCAwOwogCkBAIC0xOTYsNyArMTk5 LDkgQEAgc3RydWN0IERlZHVjZWQgewogICBzdGF0aWNfYXNzZXJ0KF9faXNfc2FtZShDT1JSRUNU X1RZUEUsIGRlY2x0eXBlKChPUEVSQU5EKSA+IDApKSk7CQlcCiAgIHN0YXRpY19hc3NlcnQoX19p c19zYW1lKENPUlJFQ1RfVFlQRSwgZGVjbHR5cGUoKE9QRVJBTkQpIDw9IDApKSk7CQlcCiAgIHN0 YXRpY19hc3NlcnQoX19pc19zYW1lKENPUlJFQ1RfVFlQRSwgZGVjbHR5cGUoKE9QRVJBTkQpID49 IDApKSk7CQlcCisgIHN0YXRpY19hc3NlcnQoX19pc19zYW1lKENPUlJFQ1RfVFlQRSwgZGVjbHR5 cGUoKE9QRVJBTkQpIDw9PiAwKSkpOwkJXAogCQkJCQkJCQkJCVwKICAgc3RhdGljX2Fzc2VydChf X2lzX3NhbWUoQ09SUkVDVF9UWVBFLCBkZWNsdHlwZSgqKE9QRVJBTkQpKSkpOwkJCVwKKyAgc3Rh dGljX2Fzc2VydChfX2lzX3NhbWUoQ09SUkVDVF9UWVBFLCBkZWNsdHlwZSgoT1BFUkFORCkgLT4q IDApKSk7CQlcCiAgIHN0YXRpY19hc3NlcnQoX19pc19zYW1lKENPUlJFQ1RfVFlQRSwgZGVjbHR5 cGUoJihPUEVSQU5EKSkpKTsJCQlcCiAgIHN0YXRpY19hc3NlcnQoX19pc19zYW1lKENPUlJFQ1Rf VFlQRSwgZGVjbHR5cGUoKE9QRVJBTkQpLCAwKSkpOwotLSAKMi4zOS4zCgo= --------------hhWcRoWZeXUP7g4VDJsQKvtB--