From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94480 invoked by alias); 18 Sep 2016 20:22:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 94434 invoked by uid 89); 18 Sep 2016 20:22:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=ongoing, STMT, Though, visited X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 18 Sep 2016 20:21:53 +0000 Received: by mail-pa0-f44.google.com with SMTP id wk8so41497142pab.1 for ; Sun, 18 Sep 2016 13:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=rSGqSiHiiwTF7fV1ZNpY6yBPSA6o/WLsYXWx5XiRrWg=; b=R+dj8BQdNqHYdXd4SC/c2NTaRBAO9jGoQ9pTlRk0C8IBhGgYXdX+RvoCETEGz94vY2 6+KaBc3b8y2UKZfNEqZKzshskhTaafvSiUpODF1Vv926Wd8MUIEWAFUYwGIda7lUTdnz pLy6CKw/YEpMVKVoPhknKwEJkWcHhxIs5BPjr/25+WU9vjR2haht8XvArEHLOXXBq/5j JZDP/PowG84ElsKyDokIh+LGZtwqeWuh1LPgSBHNqv4qUMAC3FwJkWAWRo6L+GkdKr1Y mt3/Nw/M0Xpz1ngWXno2iZFwfh/0uWGWtoqE2Q65h2a32bNW0pACM5gAQkPRkAfUkCz7 eXLA== X-Gm-Message-State: AE9vXwNicmLwh57dXuNlz4qFAG1FP9lW0E4FPCTrJbhm4in+ehu5kT8ewNMaku/vWyTYa7cN X-Received: by 10.67.23.41 with SMTP id hx9mr14525247pad.147.1474230111907; Sun, 18 Sep 2016 13:21:51 -0700 (PDT) Received: from [10.1.1.7] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id u64sm66067809pfi.0.2016.09.18.13.21.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Sep 2016 13:21:50 -0700 (PDT) Subject: Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments To: Richard Biener References: <0a1eaaf8-3ede-cd56-ffb5-40b25f94e46e@linaro.org> <98613cff-7c48-1a56-0014-6d87c35a8f26@linaro.org> <20160809214617.GB14857@tucnak.redhat.com> <7210cceb-be3b-44b1-13b7-4152e89d2a4f@linaro.org> <20160809215527.GC14857@tucnak.redhat.com> <0c53b0f3-4af6-387c-9350-95b1ae85850d@linaro.org> <20160810085703.GH14857@tucnak.redhat.com> Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" From: kugan Message-ID: <0f3b4359-f5ff-d14c-1b15-2ae647e6fd3a@linaro.org> Date: Sun, 18 Sep 2016 21:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------FDBE6E22F4FF3E14E20A4301" X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01137.txt.bz2 This is a multi-part message in MIME format. --------------FDBE6E22F4FF3E14E20A4301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 6464 Hi Richard, On 14/09/16 21:31, Richard Biener wrote: > On Fri, Sep 2, 2016 at 10:09 AM, Kugan Vivekanandarajah > wrote: >> Hi Richard, >> >> On 25 August 2016 at 22:24, Richard Biener wrote: >>> On Thu, Aug 11, 2016 at 1:09 AM, kugan >>> wrote: >>>> Hi, >>>> >>>> >>>> On 10/08/16 20:28, Richard Biener wrote: >>>>> >>>>> On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek wrote: >>>>>> >>>>>> On Wed, Aug 10, 2016 at 08:51:32AM +1000, kugan wrote: >>>>>>> >>>>>>> I see it now. The problem is we are just looking at (-1) being in the >>>>>>> ops >>>>>>> list for passing changed to rewrite_expr_tree in the case of >>>>>>> multiplication >>>>>>> by negate. If we have combined (-1), as in the testcase, we will not >>>>>>> have >>>>>>> the (-1) and will pass changed=false to rewrite_expr_tree. >>>>>>> >>>>>>> We should set changed based on what happens in try_special_add_to_ops. >>>>>>> Attached patch does this. Bootstrap and regression testing are ongoing. >>>>>>> Is >>>>>>> this OK for trunk if there is no regression. >>>>>> >>>>>> >>>>>> I think the bug is elsewhere. In particular in >>>>>> undistribute_ops_list/zero_one_operation/decrement_power. >>>>>> All those look problematic in this regard, they change RHS of statements >>>>>> to something that holds a different value, while keeping the LHS. >>>>>> So, generally you should instead just add a new stmt next to the old one, >>>>>> and adjust data structures (replace the old SSA_NAME in some ->op with >>>>>> the new one). decrement_power might be a problem here, dunno if all the >>>>>> builtins are const in all cases that DSE would kill the old one, >>>>>> Richard, any preferences for that? reset flow sensitive info + reset >>>>>> debug >>>>>> stmt uses, or something different? Though, replacing the LHS with a new >>>>>> anonymous SSA_NAME might be needed too, in case it is before SSA_NAME of >>>>>> a >>>>>> user var that doesn't yet have any debug stmts. >>>>> >>>>> >>>>> I'd say replacing the LHS is the way to go, with calling the appropriate >>>>> helper >>>>> on the old stmt to generate a debug stmt for it / its uses (would need >>>>> to look it >>>>> up here). >>>>> >>>> >>>> Here is an attempt to fix it. The problem arises when in >>>> undistribute_ops_list, we linearize_expr_tree such that NEGATE_EXPR is added >>>> (-1) MULT_EXPR (OP). Real problem starts when we handle this in >>>> zero_one_operation. Unlike what was done earlier, we now change the stmt >>>> (with propagate_op_to_signle use or by directly) such that the value >>>> computed by stmt is no longer what it used to be. Because of this, what is >>>> computed in undistribute_ops_list and rewrite_expr_tree are also changed. >>>> >>>> undistribute_ops_list already expects this but rewrite_expr_tree will not if >>>> we dont pass the changed as an argument. >>>> >>>> The way I am fixing this now is, in linearize_expr_tree, I set ops_changed >>>> to true if we change NEGATE_EXPR to (-1) MULT_EXPR (OP). Then when we call >>>> zero_one_operation with ops_changed = true, I replace all the LHS in >>>> zero_one_operation with the new SSA and replace all the uses. I also call >>>> the rewrite_expr_tree with changed = false in this case. >>>> >>>> Does this make sense? Bootstrapped and regression tested for >>>> x86_64-linux-gnu without any new regressions. >>> >>> I don't think this solves the issue. zero_one_operation associates the >>> chain starting at the first *def and it will change the intermediate values >>> of _all_ of the stmts visited until the operation to be removed is found. >>> Note that this is independent of whether try_special_add_to_ops did anything. >>> >>> Even for the regular undistribution cases we get this wrong. >>> >>> So we need to back-track in zero_one_operation, replacing each LHS >>> and in the end the op in the opvector of the main chain. That's basically >>> the same as if we'd do a regular re-assoc operation on the sub-chains. >>> Take their subops, simulate zero_one_operation by >>> appending the cancelling operation and optimizing the oplist, and then >>> materializing the associated ops via rewrite_expr_tree. >>> >> Here is a draft patch which records the stmt chain when in >> zero_one_operation and then fixes it when OP is removed. when we >> update *def, that will update the ops vector. Does this looks sane? > > Yes. A few comments below > > + /* PR72835 - Record the stmt chain that has to be updated such that > + we dont use the same LHS when the values computed are different. */ > + auto_vec stmts_to_fix; > > use auto_vec here so we get stack allocation only most > of the times Done. > if (stmt_is_power_of_op (stmt, op)) > { > + make_new_ssa_for_all_defs (def, op, stmts_to_fix); > if (decrement_power (stmt) == 1) > propagate_op_to_single_use (op, stmt, def); > > for the cases you end up with propagate_op_to_single_use its argument > stmt is handled superfluosly in the new SSA making, I suggest to pop it > from the stmts_to_fix vector in that case. I suggest to break; instead > of return in all cases and do the make_new_ssa_for_all_defs call at > the function end instead. > Done. > @@ -1253,14 +1305,18 @@ zero_one_operation (tree *def, enum tree_code > opcode, tree op) > if (gimple_assign_rhs1 (stmt2) == op) > { > tree cst = build_minus_one_cst (TREE_TYPE (op)); > + stmts_to_fix.safe_push (stmt2); > + make_new_ssa_for_all_defs (def, op, stmts_to_fix); > propagate_op_to_single_use (cst, stmt2, def); > return; > > this safe_push should be unnecessary for the above reason (others are > conditionally unnecessary). > Done. Bootstrapped and regression tested on X86_64-linux-gnu with no new regression. Is this OK? Thanks, Kugan > I thought about simplifying the whole thing by instead of clearing an > op from the chain pre-pend > one that does the job by means of visiting the chain from reassoc > itself but that doesn't work out > for RDIV_EXPR nor does it play well with undistribute handling > mutliple opportunities on the same > chain. > > Thanks, > Richard. > > >> >> Bootstrapped and regression tested on x86_64-linux-gnu with no new regressions. >> >> Thanks, >> Kugan --------------FDBE6E22F4FF3E14E20A4301 Content-Type: text/plain; charset=UTF-8; name="p.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p.txt" Content-length: 7166 ZGlmZiAtLWdpdCBhL2djYy90ZXN0c3VpdGUvZ2NjLmRnL3RyZWUtc3NhL3By NzI4MzUuYyBiL2djYy90ZXN0c3VpdGUvZ2NjLmRnL3RyZWUtc3NhL3ByNzI4 MzUuYwppbmRleCBlNjlkZTI5Li40NjhlMGYwIDEwMDY0NAotLS0gYS9nY2Mv dGVzdHN1aXRlL2djYy5kZy90cmVlLXNzYS9wcjcyODM1LmMKKysrIGIvZ2Nj L3Rlc3RzdWl0ZS9nY2MuZGcvdHJlZS1zc2EvcHI3MjgzNS5jCkBAIC0wLDAg KzEsMzcgQEAKKy8qIFBSIHRyZWUtb3B0aW1pemF0aW9uLzcyODM1LiAgKi8K Ky8qIHsgZGctZG8gcnVuIH0gKi8KKy8qIHsgZGctb3B0aW9ucyAiLU8yIiB9 ICovCisvKiB7IGRnLXJlcXVpcmUtZWZmZWN0aXZlLXRhcmdldCBpbnQzMnBs dXMgfSAqLworCitzdHJ1Y3Qgc3RydWN0XzEgeworICAgIHVuc2lnbmVkIGlu dCBtMSA6IDYgOworICAgIHVuc2lnbmVkIGludCBtMiA6IDI0IDsKKyAgICB1 bnNpZ25lZCBpbnQgbTMgOiA2IDsKK307CisKK3Vuc2lnbmVkIHNob3J0IHZh cl8zMiA9IDB4MmQxMDsKKworc3RydWN0IHN0cnVjdF8xIHMxOworCit2b2lk IGluaXQgKCkKK3sKKyAgczEubTEgPSA0OworICBzMS5tMiA9IDB4N2NhNGI4 OworICBzMS5tMyA9IDI0OworfQorCit2b2lkIGZvbyAoKQoreworICB1bnNp Z25lZCBpbnQgYworICAgID0gKCh1bnNpZ25lZCBpbnQpIHMxLm0yKSAqICgt KCh1bnNpZ25lZCBpbnQpIHMxLm0zKSkKKyAgICArICh2YXJfMzIpICogKC0o KHVuc2lnbmVkIGludCkgKHMxLm0xKSkpOworICBpZiAoYyAhPSA0MDk4ODcz OTg0KQorICAgIF9fYnVpbHRpbl9hYm9ydCAoKTsKK30KKworaW50IG1haW4g KCkKK3sKKyAgICBpbml0ICgpOworICAgIGZvbyAoKTsKKyAgICByZXR1cm4g MDsKK30KZGlmZiAtLWdpdCBhL2djYy90cmVlLXNzYS1yZWFzc29jLmMgYi9n Y2MvdHJlZS1zc2EtcmVhc3NvYy5jCmluZGV4IDdmZDc1NTAuLjI0ZTlkZDYg MTAwNjQ0Ci0tLSBhL2djYy90cmVlLXNzYS1yZWFzc29jLmMKKysrIGIvZ2Nj L3RyZWUtc3NhLXJlYXNzb2MuYwpAQCAtMTE0OCw2ICsxMTQ4LDUyIEBAIGRl Y3JlbWVudF9wb3dlciAoZ2ltcGxlICpzdG10KQogICAgIH0KIH0KIAorLyog UmVwbGFjZSBTU0EgZGVmaW5lZCBieSBTVE1UIGFuZCByZXBsYWNlIGFsbCBp dHMgdXNlcyB3aXRoIG5ldworICAgU1NBLiAgQWxzbyByZXR1cm4gdGhlIG5l dyBTU0EuICAqLworCitzdGF0aWMgdHJlZQorbWFrZV9uZXdfc3NhX2Zvcl9k ZWYgKGdpbXBsZSAqc3RtdCkKK3sKKyAgZ2ltcGxlICp1c2Vfc3RtdDsKKyAg dXNlX29wZXJhbmRfcCB1c2U7CisgIGltbV91c2VfaXRlcmF0b3IgaXRlcjsK KyAgdHJlZSBuZXdfbGhzOworICB0cmVlIGxocyA9IGdpbXBsZV9hc3NpZ25f bGhzIChzdG10KTsKKworICBuZXdfbGhzID0gbWFrZV9zc2FfbmFtZSAoVFJF RV9UWVBFIChsaHMpKTsKKyAgZ2ltcGxlX3NldF9saHMgKHN0bXQsIG5ld19s aHMpOworCisgIC8qIEFsc28gbmVlZCB0byB1cGRhdGUgR0lNUExFX0RFQlVH cy4gICovCisgIEZPUl9FQUNIX0lNTV9VU0VfU1RNVCAodXNlX3N0bXQsIGl0 ZXIsIGxocykKKyAgICB7CisgICAgICBGT1JfRUFDSF9JTU1fVVNFX09OX1NU TVQgKHVzZSwgaXRlcikKKwlTRVRfVVNFICh1c2UsIG5ld19saHMpOworICAg ICAgdXBkYXRlX3N0bXQgKHVzZV9zdG10KTsKKyAgICB9CisgIHJldHVybiBu ZXdfbGhzOworfQorCisvKiBSZXBsYWNlIGFsbCBTU0FzIGRlZmluZWQgaW4g U1RNVFNfVE9fRklYIGFuZCByZXBsYWNlIGl0cworICAgdXNlcyB3aXRoIG5l dyBTU0FzLiAgQWxzbyBkbyB0aGlzIGZvciB0aGUgc3RtdCB0aGF0IGRlZmlu ZXMgREVGCisgICBpZiAqREVGIGlzIG5vdCBPUC4gICovCisKK3N0YXRpYyB2 b2lkCittYWtlX25ld19zc2FfZm9yX2FsbF9kZWZzICh0cmVlICpkZWYsIHRy ZWUgb3AsCisJCQkgICBhdXRvX3ZlYzxnaW1wbGUgKiwgNjQ+ICZzdG10c190 b19maXgpCit7CisgIHVuc2lnbmVkIGk7CisgIGdpbXBsZSAqc3RtdDsKKwor ICBpZiAoKmRlZiAhPSBvcAorICAgICAgJiYgVFJFRV9DT0RFICgqZGVmKSA9 PSBTU0FfTkFNRQorICAgICAgJiYgKHN0bXQgPSBTU0FfTkFNRV9ERUZfU1RN VCAoKmRlZikpCisgICAgICAmJiBnaW1wbGVfY29kZSAoc3RtdCkgIT0gR0lN UExFX05PUCkKKyAgICAqZGVmID0gbWFrZV9uZXdfc3NhX2Zvcl9kZWYgKHN0 bXQpOworCisgIEZPUl9FQUNIX1ZFQ19FTFQgKHN0bXRzX3RvX2ZpeCwgaSwg c3RtdCkKKyAgICBtYWtlX25ld19zc2FfZm9yX2RlZiAoc3RtdCk7Cit9CisK IC8qIEZpbmQgdGhlIHNpbmdsZSBpbW1lZGlhdGUgdXNlIG9mIFNUTVQncyBM SFMsIGFuZCByZXBsYWNlIGl0CiAgICB3aXRoIE9QLiAgUmVtb3ZlIFNUTVQu ICBJZiBTVE1UJ3MgTEhTIGlzIHRoZSBzYW1lIGFzICpERUYsCiAgICByZXBs YWNlICpERUYgd2l0aCBPUCBhcyB3ZWxsLiAgKi8KQEAgLTExODYsNiArMTIz Miw5IEBAIHN0YXRpYyB2b2lkCiB6ZXJvX29uZV9vcGVyYXRpb24gKHRyZWUg KmRlZiwgZW51bSB0cmVlX2NvZGUgb3Bjb2RlLCB0cmVlIG9wKQogewogICBn aW1wbGUgKnN0bXQgPSBTU0FfTkFNRV9ERUZfU1RNVCAoKmRlZik7CisgIC8q IFBSNzI4MzUgLSBSZWNvcmQgdGhlIHN0bXQgY2hhaW4gdGhhdCBoYXMgdG8g YmUgdXBkYXRlZCBzdWNoIHRoYXQKKyAgICAgd2UgZG9udCB1c2UgdGhlIHNh bWUgTEhTIHdoZW4gdGhlIHZhbHVlcyBjb21wdXRlZCBhcmUgZGlmZmVyZW50 LiAgKi8KKyAgYXV0b192ZWM8Z2ltcGxlICosIDY0PiBzdG10c190b19maXg7 CiAKICAgZG8KICAgICB7CkBAIC0xMTk2LDIzICsxMjQ1LDI5IEBAIHplcm9f b25lX29wZXJhdGlvbiAodHJlZSAqZGVmLCBlbnVtIHRyZWVfY29kZSBvcGNv ZGUsIHRyZWUgb3ApCiAJICBpZiAoc3RtdF9pc19wb3dlcl9vZl9vcCAoc3Rt dCwgb3ApKQogCSAgICB7CiAJICAgICAgaWYgKGRlY3JlbWVudF9wb3dlciAo c3RtdCkgPT0gMSkKLQkJcHJvcGFnYXRlX29wX3RvX3NpbmdsZV91c2UgKG9w LCBzdG10LCBkZWYpOwotCSAgICAgIHJldHVybjsKKwkJeworCQkgIGlmIChz dG10c190b19maXgubGVuZ3RoICgpID4gMCkKKwkJICAgIHN0bXRzX3RvX2Zp eC5wb3AgKCk7CisJCSAgcHJvcGFnYXRlX29wX3RvX3NpbmdsZV91c2UgKG9w LCBzdG10LCBkZWYpOworCQl9CisJICAgICAgYnJlYWs7CiAJICAgIH0KIAkg IGVsc2UgaWYgKGdpbXBsZV9hc3NpZ25fcmhzX2NvZGUgKHN0bXQpID09IE5F R0FURV9FWFBSKQogCSAgICB7CiAJICAgICAgaWYgKGdpbXBsZV9hc3NpZ25f cmhzMSAoc3RtdCkgPT0gb3ApCiAJCXsKIAkJICB0cmVlIGNzdCA9IGJ1aWxk X21pbnVzX29uZV9jc3QgKFRSRUVfVFlQRSAob3ApKTsKKwkJICBpZiAoc3Rt dHNfdG9fZml4Lmxlbmd0aCAoKSA+IDApCisJCSAgICBzdG10c190b19maXgu cG9wICgpOwogCQkgIHByb3BhZ2F0ZV9vcF90b19zaW5nbGVfdXNlIChjc3Qs IHN0bXQsIGRlZik7Ci0JCSAgcmV0dXJuOworCQkgIGJyZWFrOwogCQl9CiAJ ICAgICAgZWxzZSBpZiAoaW50ZWdlcl9taW51c19vbmVwIChvcCkKIAkJICAg ICAgIHx8IHJlYWxfbWludXNfb25lcCAob3ApKQogCQl7CiAJCSAgZ2ltcGxl X2Fzc2lnbl9zZXRfcmhzX2NvZGUKIAkJICAgIChzdG10LCBUUkVFX0NPREUg KGdpbXBsZV9hc3NpZ25fcmhzMSAoc3RtdCkpKTsKLQkJICByZXR1cm47CisJ CSAgYnJlYWs7CiAJCX0KIAkgICAgfQogCX0KQEAgLTEyMjgsOCArMTI4Mywx MCBAQCB6ZXJvX29uZV9vcGVyYXRpb24gKHRyZWUgKmRlZiwgZW51bSB0cmVl X2NvZGUgb3Bjb2RlLCB0cmVlIG9wKQogCXsKIAkgIGlmIChuYW1lID09IG9w KQogCSAgICBuYW1lID0gZ2ltcGxlX2Fzc2lnbl9yaHMyIChzdG10KTsKKwkg IGlmIChzdG10c190b19maXgubGVuZ3RoICgpID4gMCkKKwkgICAgc3RtdHNf dG9fZml4LnBvcCAoKTsKIAkgIHByb3BhZ2F0ZV9vcF90b19zaW5nbGVfdXNl IChuYW1lLCBzdG10LCBkZWYpOwotCSAgcmV0dXJuOworCSAgYnJlYWs7CiAJ fQogCiAgICAgICAvKiBXZSBtaWdodCBoYXZlIGEgbXVsdGlwbHkgb2YgdHdv IF9fYnVpbHRpbl9wb3cqIGNhbGxzLCBhbmQKQEAgLTEyNDUsNyArMTMwMiw5 IEBAIHplcm9fb25lX29wZXJhdGlvbiAodHJlZSAqZGVmLCBlbnVtIHRyZWVf Y29kZSBvcGNvZGUsIHRyZWUgb3ApCiAJICAgIHsKIAkgICAgICBpZiAoZGVj cmVtZW50X3Bvd2VyIChzdG10MikgPT0gMSkKIAkJcHJvcGFnYXRlX29wX3Rv X3NpbmdsZV91c2UgKG9wLCBzdG10MiwgZGVmKTsKLQkgICAgICByZXR1cm47 CisJICAgICAgZWxzZQorCQlzdG10c190b19maXguc2FmZV9wdXNoIChzdG10 Mik7CisJICAgICAgYnJlYWs7CiAJICAgIH0KIAkgIGVsc2UgaWYgKGlzX2dp bXBsZV9hc3NpZ24gKHN0bXQyKQogCQkgICAmJiBnaW1wbGVfYXNzaWduX3Jo c19jb2RlIChzdG10MikgPT0gTkVHQVRFX0VYUFIpCkBAIC0xMjU0LDE0ICsx MzEzLDE1IEBAIHplcm9fb25lX29wZXJhdGlvbiAodHJlZSAqZGVmLCBlbnVt IHRyZWVfY29kZSBvcGNvZGUsIHRyZWUgb3ApCiAJCXsKIAkJICB0cmVlIGNz dCA9IGJ1aWxkX21pbnVzX29uZV9jc3QgKFRSRUVfVFlQRSAob3ApKTsKIAkJ ICBwcm9wYWdhdGVfb3BfdG9fc2luZ2xlX3VzZSAoY3N0LCBzdG10MiwgZGVm KTsKLQkJICByZXR1cm47CisJCSAgYnJlYWs7CiAJCX0KIAkgICAgICBlbHNl IGlmIChpbnRlZ2VyX21pbnVzX29uZXAgKG9wKQogCQkgICAgICAgfHwgcmVh bF9taW51c19vbmVwIChvcCkpCiAJCXsKKwkJICBzdG10c190b19maXguc2Fm ZV9wdXNoIChzdG10Mik7CiAJCSAgZ2ltcGxlX2Fzc2lnbl9zZXRfcmhzX2Nv ZGUKIAkJICAgIChzdG10MiwgVFJFRV9DT0RFIChnaW1wbGVfYXNzaWduX3Jo czEgKHN0bXQyKSkpOwotCQkgIHJldHVybjsKKwkJICBicmVhazsKIAkJfQog CSAgICB9CiAJfQpAQCAtMTI3MCw4ICsxMzMwLDEyIEBAIHplcm9fb25lX29w ZXJhdGlvbiAodHJlZSAqZGVmLCBlbnVtIHRyZWVfY29kZSBvcGNvZGUsIHRy ZWUgb3ApCiAgICAgICBnY2NfYXNzZXJ0IChuYW1lICE9IG9wCiAJCSAgJiYg VFJFRV9DT0RFIChuYW1lKSA9PSBTU0FfTkFNRSk7CiAgICAgICBzdG10ID0g U1NBX05BTUVfREVGX1NUTVQgKG5hbWUpOworICAgICAgc3RtdHNfdG9fZml4 LnNhZmVfcHVzaCAoc3RtdCk7CiAgICAgfQogICB3aGlsZSAoMSk7CisKKyAg aWYgKHN0bXRzX3RvX2ZpeC5sZW5ndGggKCkgPiAwKQorICAgIG1ha2VfbmV3 X3NzYV9mb3JfYWxsX2RlZnMgKGRlZiwgb3AsIHN0bXRzX3RvX2ZpeCk7CiB9 CiAKIC8qIFJldHVybnMgdHJ1ZSBpZiBzdGF0ZW1lbnQgUzEgZG9taW5hdGVz IHN0YXRlbWVudCBTMi4gIExpa2UK --------------FDBE6E22F4FF3E14E20A4301--