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.129.124]) by sourceware.org (Postfix) with ESMTPS id 5F2963858C2C for ; Wed, 22 Dec 2021 05:22:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F2963858C2C Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-491-BvAFq46sMFmD2aRNggODAA-1; Wed, 22 Dec 2021 00:22:39 -0500 X-MC-Unique: BvAFq46sMFmD2aRNggODAA-1 Received: by mail-qv1-f70.google.com with SMTP id g15-20020a0562141ccf00b003cada9e7e2fso1275933qvd.1 for ; Tue, 21 Dec 2021 21:22:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=zuvIpART5Mo58gTkOqyQnGuEOqG/dhwuFW6aHLtqcg4=; b=spmEcte8pnCCPTS0XN4GOkSjKwCQ1v8vmbATKRxpANjIwW+cy2MP06CjnE00nBzc6L lsKoV3D/kVta8aR/kWB4Be+UqmXSYKmswaMK8uTFnzRTB7TpqU7bD4pEUsgfuyRyvFLs dJRNMJOzVoUi5429CkyZ+oVdOoxgQlg9ASakumtoJRUigb1hkshTHi0EMjdzW+2jC2W+ GD8pOV6Ynf6Ct/6A32Cr5mePUoCH42ffA6sHTWUu/ewaxCRQDc4LhLLL0fbDCl8kUAbP xUk9VrsG0IlEo67U5eWaAnnjVWjn855y2Jac3/8+lOUtXwzUcPygawP3hj7EA7BQZIYB Wfwg== X-Gm-Message-State: AOAM5335iIMdKqeUJLqrevHRjrrtTykdmPZDBZA9kmCV6NjR3lz2wxhR DfHEf4Fc5btcqQ8UvSotty5utGsjIBs8DAc/d2XRf9Yc8oTxAwHqgtvCB3jSa6tgQBb9x1SpttN /7CjwZG+bajTpJldVSQ== X-Received: by 2002:a05:622a:64e:: with SMTP id a14mr1048596qtb.496.1640150558382; Tue, 21 Dec 2021 21:22:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAsrgAmvAD+HXK2qopiao5AL85rGyeMwuD3gzz2n3/jd8TkciC1o4TM8z+Ely1w3vfNFw6WA== X-Received: by 2002:a05:622a:64e:: with SMTP id a14mr1048586qtb.496.1640150557899; Tue, 21 Dec 2021 21:22:37 -0800 (PST) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id y124sm940555qkd.105.2021.12.21.21.22.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Dec 2021 21:22:36 -0800 (PST) Message-ID: <8bec1e70-7ea6-b885-2c89-443d96822efd@redhat.com> Date: Wed, 22 Dec 2021 00:22:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] c++: CTAD within alias template [PR91911] To: Patrick Palka Cc: GCC Patches References: <20210624204529.4136660-1-ppalka@redhat.com> <3802ce35-3e48-fb97-8868-d1274ed0a778@redhat.com> <0719adf2-7a17-a8a7-9374-cbfa41846499@redhat.com> <8b6edd86-9db0-f6e2-386f-4693d1692f5f@idea> <67855539-bf99-ac7-a995-35871cd23712@idea> <7f944b48-7c8f-755a-8cea-0880cbda4ccc@redhat.com> <7d2f4e2b-4e31-4ae7-8d80-5676a17e9de5@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------sOmB11bsBdHvJE5RWWT3b8ys" Content-Language: en-US X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Wed, 22 Dec 2021 05:22:43 -0000 This is a multi-part message in MIME format. --------------sOmB11bsBdHvJE5RWWT3b8ys Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/21/21 14:08, Patrick Palka wrote: > On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote: >> >> On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote: >>> >>> On 6/30/21 4:18 PM, Patrick Palka wrote: >>>> On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill wrote: >>>>> >>>>> On 6/30/21 11:58 AM, Patrick Palka wrote: >>>>>> On Wed, 30 Jun 2021, Patrick Palka wrote: >>>>>> >>>>>>> On Fri, 25 Jun 2021, Jason Merrill wrote: >>>>>>> >>>>>>>> On 6/25/21 1:11 PM, Patrick Palka wrote: >>>>>>>>> On Fri, 25 Jun 2021, Jason Merrill wrote: >>>>>>>>> >>>>>>>>>> On 6/24/21 4:45 PM, Patrick Palka wrote: >>>>>>>>>>> In the first testcase below, during parsing of the alias template >>>>>>>>>>> ConstSpanType, transparency of alias template specializations means we >>>>>>>>>>> replace SpanType with SpanType's substituted definition. But this >>>>>>>>>>> substitution lowers the level of the CTAD placeholder for span(T()) from >>>>>>>>>>> 2 to 1, and so the later instantiantion of ConstSpanType >>>>>>>>>>> erroneously substitutes this CTAD placeholder with the template argument >>>>>>>>>>> at level 1 index 0, i.e. with int, before we get a chance to perform the >>>>>>>>>>> CTAD. >>>>>>>>>>> >>>>>>>>>>> In light of this, it seems we should avoid level lowering when >>>>>>>>>>> substituting through through the type-id of a dependent alias template >>>>>>>>>>> specialization. To that end this patch makes lookup_template_class_1 >>>>>>>>>>> pass tf_partial to tsubst in this situation. >>>>>>>>>> >>>>>>>>>> This makes sense, but what happens if SpanType is a member template, so >>>>>>>>>> that >>>>>>>>>> the levels of it and ConstSpanType don't match? Or the other way around? >>>>>>>>> >>>>>>>>> If SpanType is a member template of say the class template A (and >>>>>>>>> thus its level is greater than ConstSpanType): >>>>>>>>> >>>>>>>>> template >>>>>>>>> struct A { >>>>>>>>> template >>>>>>>>> using SpanType = decltype(span(T())); >>>>>>>>> }; >>>>>>>>> >>>>>>>>> template >>>>>>>>> using ConstSpanType = span>>>>>>>> A::SpanType::value_type>; >>>>>>>>> >>>>>>>>> using type = ConstSpanType; >>>>>>>>> >>>>>>>>> then this case luckily works even without the patch because >>>>>>>>> instantiate_class_template now reuses the specialization A::SpanType >>>>>>>>> that was formed earlier during instantiation of A, where we >>>>>>>>> substitute only a single level of template arguments, so the level of >>>>>>>>> the CTAD placeholder inside the defining-type-id of this specialization >>>>>>>>> dropped from 3 to 2, so still more than the level of ConstSpanType. >>>>>>>>> >>>>>>>>> This luck is short-lived though, because if we replace >>>>>>>>> A::SpanType with say A::SpanType then the testcase >>>>>>>>> breaks again (without the patch) because we no longer can reuse that >>>>>>>>> specialization, so we instead form it on the spot by substituting two >>>>>>>>> levels of template arguments (U=int,T=T) into the defining-type-id, >>>>>>>>> causing the level of the placeholder to drop to 1. I think the patch >>>>>>>>> causes its level to remain 3 (though I guess it should really be 2). >>>>>>>>> >>>>>>>>> >>>>>>>>> For the other way around, if ConstSpanType is a member template of >>>>>>>>> say the class template B (and thus its level is greater than >>>>>>>>> SpanType): >>>>>>>>> >>>>>>>>> template >>>>>>>>> using SpanType = decltype(span(T())); >>>>>>>>> >>>>>>>>> template >>>>>>>>> struct B { >>>>>>>>> template >>>>>>>>> using ConstSpanType = span::value_type>; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> using type = B::ConstSpanType; >>>>>>>>> >>>>>>>>> then tf_partial doesn't help here at all; we end up substituting 'int' >>>>>>>>> for the CTAD placeholder... What it seems we need is to _increase_ the >>>>>>>>> level of the CTAD placeholder from 2 to 3 during the dependent >>>>>>>>> substitution.. >>>>>>>>> >>>>>>>>> Hmm, rather than messing with tf_partial, which is apparently only a >>>>>>>>> partial solution, maybe we should just make tsubst never substitute a >>>>>>>>> CTAD placeholder -- they should always be resolved from do_class_deduction, >>>>>>>>> and their level doesn't really matter otherwise. (But we'd still want >>>>>>>>> to substitute into the CLASS_PLACEHOLDER_TEMPLATE of the placeholder in >>>>>>>>> case it's a template template parm.) Something like: >>>>>>>>> >>>>>>>>> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c >>>>>>>>> index 5107bfbf9d1..dead651ed84 100644 >>>>>>>>> --- a/gcc/cp/pt.c >>>>>>>>> +++ b/gcc/cp/pt.c >>>>>>>>> @@ -15552,7 +15550,8 @@ tsubst (tree t, tree args, tsubst_flags_t complain, >>>>>>>>> tree in_decl) >>>>>>>>> levels = TMPL_ARGS_DEPTH (args); >>>>>>>>> if (level <= levels >>>>>>>>> - && TREE_VEC_LENGTH (TMPL_ARGS_LEVEL (args, level)) > 0) >>>>>>>>> + && TREE_VEC_LENGTH (TMPL_ARGS_LEVEL (args, level)) > 0 >>>>>>>>> + && !template_placeholder_p (t)) >>>>>>>>> { >>>>>>>>> arg = TMPL_ARG (args, level, idx); >>>>>>>>> >>>>>>>>> seems to work better. >>>>>>>> >>>>>>>> Makes sense. >>>>>>> >>>>>>> Here's a patch that implements that. I reckon it's good to have both >>>>>>> workarounds in place because the tf_partial workaround is necessary to >>>>>>> accept class-deduction93a.C below, and the tsubst workaround is >>>>>>> necessary to accept class-deduction-92b.C below. >>>>>> >>>>>> Whoops, forgot to git-add class-deduction93a.C: >>>>>> >>>>>> -- >8 -- >>>>>> >>>>>> Subject: [PATCH] c++: CTAD within alias template [PR91911] >>>>>> >>>>>> In the first testcase below, during parsing of the alias template >>>>>> ConstSpanType, transparency of alias template specializations means we >>>>>> replace SpanType with SpanType's substituted definition. But this >>>>>> substitution lowers the level of the CTAD placeholder for span{T()} from >>>>>> 2 to 1, and so the later instantiation of ConstSpanType erroneously >>>>>> substitutes this CTAD placeholder with the template argument at level 1 >>>>>> index 0, i.e. with int, before we get a chance to perform the CTAD. >>>>>> >>>>>> In light of this, it seems we should avoid level lowering when >>>>>> substituting through the type-id of a dependent alias template >>>>>> specialization. To that end this patch makes lookup_template_class_1 >>>>>> pass tf_partial to tsubst in this situation. >>>>>> >>>>>> Unfortunately, using tf_partial alone isn't sufficient because the >>>>>> template context in which we perform the dependent substitution may >>>>>> have more levels than the substituted alias template and so we >>>>>> end up substituting the CTAD placeholder anyway, as in >>>>>> class-deduction92b.C below. (There, it seems we'd need to _increase_ >>>>>> the level of the placeholder for span{T()} from 2 to 3 during the >>>>>> dependent substitution.) Since we never want to resolve a CTAD >>>>>> placeholder outside of CTAD proper, this patch takes the relatively >>>>>> ad-hoc approach of making tsubst explicitly avoid doing so. >>>>>> >>>>>> This tsubst workaround doesn't obviate the tf_partial workaround because >>>>>> it's still desirable to avoid prematurely level lowering a CTAD placeholder: >>>>>> it's less work for the compiler, and it gives us a chance to substitute >>>>>> a template placeholder that's a template template parameter with a >>>>>> concrete template template argument, as in the last testcase below. >>>>> >>>>> Hmm, what if we combine the template template parameter with the level >>>>> mismatch? >>>> >>>> So for e.g. >>>> >>>> template class Tmpl> >>>> using CallableTraitT = CallableTrait; >>>> >>>> template >>>> struct A { >>>> template class Tmpl> >>>> using ReturnType = typename CallableTraitT::ReturnType; >>>> }; >>>> >>>> using type = A::ReturnType; >>>> using type = int; >>>> >>>> sadly we crash, because during the dependent substitution of the >>>> innermost arguments into the defining-type-id, tf_partial means we >>>> don't lower the level of the CTAD placeholder and therefore don't >>>> substitute into CLASS_PLACEHOLDER_TEMPLATE, so >>>> CLASS_PLACEHOLDER_TEMPLATE remains a template template parm at index 1 >>>> level 1 (as opposed to level 2). Later during the full >>>> instantiation, there is no such template template argument at that >>>> position (it's at index 1 level 2 rather). >>>> >>>> To handle this testcase, it seems we need a way to substitute into >>>> CTAD placeholders without lowering their level I guess. >>> >>> Or replacing their level with the appropriate level for the args we're >>> dealing with/whether tf_partial is set? >> >> That sounds like it might work for CTAD placeholders, since we never >> want to replace them via tsubst anyway. But I suppose a complete >> solution to this problem would also need to adjust the level of 'auto' >> that appears inside unevaluated lambdas (and C++23 auto(x) now too, I >> guess). And the tricky part with those is that we do sometimes want >> to replace 'auto's via tsubst, in particular during >> do_auto_deduction.. >> >> I wonder if for now the v1 patch (the one consisting of just the >> lookup_template_class_1 change) can go in? I noticed that it also >> fixes a slew of (essentially duplicate) PRs about simple uses of >> unevaluated lambdas within alias templates: 100594, 92211, 103569, >> 102680, 101315, 101013, 92707. (The template_placeholder_p change in >> the v2 patch I realized is buggy -- by avoiding substitution into the >> CTAD placeholder, we fall back to level-lowering, but since level <= levels we end up creating a CTAD > placeholder with nonpositive level. > - t = tsubst (TREE_TYPE (gen_tmpl), arglist, complain, in_decl); > + /* When substituting a dependent alias template specialization, > + we pass tf_partial to avoid lowering the level of any 'auto' > + in its type-id which might correspond to CTAD placeholders. */ > + t = tsubst (TREE_TYPE (gen_tmpl), arglist, > + complain | (is_dependent_type * tf_partial), > + in_decl); So, if we aren't changing any containing template scopes from dependent to non-dependent, we don't want to mess with levels. I think is_dependent_type is a bit too broad here; I'd expect this could cause trouble when e.g. instantiating a class A with a member template B and we have both B and an auto in the signature of a member template. I think what we want to check is whether the outermost args are dependent. It would also be safer to handle adding tf_partial for alias templates in instantiate_alias_template rather than lookup_template_class. Perhaps in alias_ctad_tweaks as well. I tried adding an assert that tf_partial is set any time we see dependent outermost args; I expected to need to override that for deduction guide rewriting, but also seem to hit problems in concepts and TTP. Attached in case you're interested; I don't think this is going to become a patch suitable for GCC 12. The use of uses_template_parms_level was a kludge because dependent_template_arg_p returns true for null args. Jason --------------sOmB11bsBdHvJE5RWWT3b8ys Content-Type: text/x-patch; charset=UTF-8; name="0001-assert.patch" Content-Disposition: attachment; filename="0001-assert.patch" Content-Transfer-Encoding: base64 RnJvbSA0MGQ2NjM5Nzk4ODYyODVlNDdhMjE0OTUwN2UwMmNiMDUyYzIyMWJlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKYXNvbiBNZXJyaWxsIDxqYXNvbkByZWRoYXQuY29tPgpEYXRl OiBUdWUsIDIxIERlYyAyMDIxIDE3OjI4OjEyIC0wNTAwClN1YmplY3Q6IFtQQVRDSCAxLzRdIGFz c2VydApUbzogZ2NjLXBhdGNoZXNAZ2NjLmdudS5vcmcKCi0tLQogZ2NjL2NwL2NwLXRyZWUuaCB8 ICAxICsKIGdjYy9jcC9wdC5jICAgICAgfCAxNSArKysrKysrKysrKysrKy0KIDIgZmlsZXMgY2hh bmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2djYy9j cC9jcC10cmVlLmggYi9nY2MvY3AvY3AtdHJlZS5oCmluZGV4IDVmYzllNWVmZGFiLi5hMWVkYmEy MTIzYSAxMDA2NDQKLS0tIGEvZ2NjL2NwL2NwLXRyZWUuaAorKysgYi9nY2MvY3AvY3AtdHJlZS5o CkBAIC01NTE1LDYgKzU1MTUsNyBAQCBlbnVtIHRzdWJzdF9mbGFncyB7CiAJCQkJKGJ1aWxkX3Rh cmdldF9leHByIGFuZCBmcmllbmRzKSAqLwogICB0Zl9ub3JtID0gMSA8PCAxMSwJCSAvKiBCdWls ZCBkaWFnbm9zdGljIGluZm9ybWF0aW9uIGR1cmluZwogCQkJCSAgICBjb25zdHJhaW50IG5vcm1h bGl6YXRpb24uICAqLworICB0Zl9jdGFkID0gMSA8PCAxMiwJICAgICAvKiBCdWlsZGluZyBhIGRl ZHVjdGlvbiBndWlkZS4gICovCiAgIC8qIENvbnZlbmllbnQgc3Vic3RpdHV0aW9uIGZsYWdzIGNv bWJpbmF0aW9ucy4gICovCiAgIHRmX3dhcm5pbmdfb3JfZXJyb3IgPSB0Zl93YXJuaW5nIHwgdGZf ZXJyb3IKIH07CmRpZmYgLS1naXQgYS9nY2MvY3AvcHQuYyBiL2djYy9jcC9wdC5jCmluZGV4IGEx MTVlMWQxMjhjLi5lZjgzNTg4ZTJhOSAxMDA2NDQKLS0tIGEvZ2NjL2NwL3B0LmMKKysrIGIvZ2Nj L2NwL3B0LmMKQEAgLTE1NzA4LDYgKzE1NzA4LDEwIEBAIHRzdWJzdCAodHJlZSB0LCB0cmVlIGFy Z3MsIHRzdWJzdF9mbGFnc190IGNvbXBsYWluLCB0cmVlIGluX2RlY2wpCiAJaWYgKGNvbXBsYWlu ICYgdGZfcGFydGlhbCkKIAkgIHJldHVybiB0OwogCisJaWYgKCEoY29tcGxhaW4gJiB0Zl9jdGFk KQorCSAgICAmJiB1c2VzX3RlbXBsYXRlX3Bhcm1zX2xldmVsIChUTVBMX0FSR1NfTEVWRUwgKGFy Z3MsIDEpLCAxKSkKKwkgIGdjY19hc3NlcnQgKGZhbHNlKTsKKwogCS8qIElmIHdlIGdldCBoZXJl LCB3ZSBtdXN0IGhhdmUgYmVlbiBsb29raW5nIGF0IGEgcGFybSBmb3IgYQogCSAgIG1vcmUgZGVl cGx5IG5lc3RlZCB0ZW1wbGF0ZS4gIE1ha2UgYSBuZXcgdmVyc2lvbiBvZiB0aGlzCiAJICAgdGVt cGxhdGUgcGFyYW1ldGVyLCBidXQgd2l0aCBhIGxvd2VyIGxldmVsLiAgKi8KQEAgLTIxNTQ1LDYg KzIxNTQ5LDkgQEAgaW5zdGFudGlhdGVfYWxpYXNfdGVtcGxhdGUgKHRyZWUgdG1wbCwgdHJlZSBh cmdzLCB0c3Vic3RfZmxhZ3NfdCBjb21wbGFpbikKIAkJCQkgICAgIC8qcmVxdWlyZV9hbGxfYXJn cz0qL3RydWUsCiAJCQkJICAgICAvKnVzZV9kZWZhdWx0X2FyZ3M9Ki90cnVlKTsKIAorICBpZiAo YXJncyA9PSBlcnJvcl9tYXJrX25vZGUpCisgICAgcmV0dXJuIGVycm9yX21hcmtfbm9kZTsKKwog ICAvKiBGSVhNRSBjaGVjayBmb3Igc2F0aXNmYWN0aW9uIGluIGNoZWNrX2luc3RhbnRpYXRlZF9h cmdzLiAgKi8KICAgaWYgKGZsYWdfY29uY2VwdHMKICAgICAgICYmICFhbnlfZGVwZW5kZW50X3Rl bXBsYXRlX2FyZ3VtZW50c19wIChhcmdzKQpAQCAtMjE1NjEsNiArMjE1NjgsMTAgQEAgaW5zdGFu dGlhdGVfYWxpYXNfdGVtcGxhdGUgKHRyZWUgdG1wbCwgdHJlZSBhcmdzLCB0c3Vic3RfZmxhZ3Nf dCBjb21wbGFpbikKIAogICBpZiAoIXB1c2hfdGluc3RfbGV2ZWwgKHRtcGwsIGFyZ3MpKQogICAg IHJldHVybiBlcnJvcl9tYXJrX25vZGU7CisKKyAgaWYgKHVzZXNfdGVtcGxhdGVfcGFybXNfbGV2 ZWwgKFRNUExfQVJHU19MRVZFTCAoYXJncywgMSksIDEpKQorICAgIGNvbXBsYWluIHw9IHRmX3Bh cnRpYWw7CisKICAgdHJlZSByID0gaW5zdGFudGlhdGVfdGVtcGxhdGUgKHRtcGwsIGFyZ3MsIGNv bXBsYWluKTsKICAgcG9wX3RpbnN0X2xldmVsICgpOwogCkBAIC0yOTAyNiw2ICsyOTAzNyw4IEBA IGJ1aWxkX2RlZHVjdGlvbl9ndWlkZSAodHJlZSB0eXBlLCB0cmVlIGN0b3IsIHRyZWUgb3V0ZXJf YXJncywgdHN1YnN0X2ZsYWdzX3QgY29tCiAgIGxvY2F0aW9uX3QgbG9jOwogICB0cmVlIGZuX3Rt cGwgPSBOVUxMX1RSRUU7CiAKKyAgY29tcGxhaW4gfD0gdGZfY3RhZDsKKwogICBpZiAob3V0ZXJf YXJncykKICAgICB7CiAgICAgICArK3Byb2Nlc3NpbmdfdGVtcGxhdGVfZGVjbDsKQEAgLTI5NDI3 LDcgKzI5NDQwLDcgQEAgYWxpYXNfY3RhZF90d2Vha3MgKHRyZWUgdG1wbCwgdHJlZSB1Z3VpZGVz KQogICAgICBjb25zdHJhaW50IHdlIGRvbid0IG5lZWQgdG8gZGVkdWNlIHRoZW0gYWdhaW4sIHdl IGNhbiBqdXN0IGNoZWNrIHdoZXRoZXIKICAgICAgdGhlIGRlZHVjdGlvbiBwcm9kdWNlZCB0aGUg ZGVzaXJlZCByZXN1bHQuICAqLwogCi0gIHRzdWJzdF9mbGFnc190IGNvbXBsYWluID0gdGZfd2Fy bmluZ19vcl9lcnJvcjsKKyAgdHN1YnN0X2ZsYWdzX3QgY29tcGxhaW4gPSB0Zl93YXJuaW5nX29y X2Vycm9yIHwgdGZfcGFydGlhbDsKICAgdHJlZSBhdHlwZSA9IFRSRUVfVFlQRSAodG1wbCk7CiAg IHRyZWUgYWd1aWRlcyA9IE5VTExfVFJFRTsKICAgdHJlZSBhdHBhcm1zID0gSU5ORVJNT1NUX1RF TVBMQVRFX1BBUk1TIChERUNMX1RFTVBMQVRFX1BBUk1TICh0bXBsKSk7Ci0tIAoyLjI3LjAKCg== --------------sOmB11bsBdHvJE5RWWT3b8ys--