From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender4-pp-o91.zoho.com (sender4-pp-o91.zoho.com [136.143.188.91]) by sourceware.org (Postfix) with ESMTPS id 44BEF383303A; Fri, 18 Jun 2021 21:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 44BEF383303A ARC-Seal: i=1; a=rsa-sha256; t=1624050725; cv=none; d=zohomail.com; s=zohoarc; b=GgWIaVQWfChTbHl06rllHsjCFdTn341psnnK2BhVAjqWssJe7OQFON7JsIAC8lZ6zybm00OdR/+ChVAKQpZ47irTYcTkMi7zj9Z1HEcMtJr9//Ptg7Z97Eo4Dg9qUoN84P0Kf5i2lpaDtdVDxvPvZNtOda/OzeYNrXNWTM6t1qk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1624050725; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=R8+btBuzFJgPtrmXWaLGtiXZ25BMXJT3VNzk5rfHk6s=; b=NchEiHd+cTrW4QkS03CugdewNprpjSCBJZMELE8R3uQfUHCsF3QcInTFnf+vBtxXdoHvLnWPOsJWzjrgAqZO6Mx8iws2is/0ej1RMDWYAHsqg1lQLKJQzRu+VSUEFi2/Xm5Kg8NCxNKZpzLFzTVgCcHgaUQpdr5Sy3Aex6/aTaQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=bouanto@zoho.com; dmarc=pass header.from= Received: from [192.168.1.174] (38.87.11.6 [38.87.11.6]) by mx.zohomail.com with SMTPS id 1624050720613994.0847377728423; Fri, 18 Jun 2021 14:12:00 -0700 (PDT) Message-ID: Subject: Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498] From: Antoni Boucher To: David Malcolm Cc: jit@gcc.gnu.org, Antoni Boucher via Gcc-patches Date: Fri, 18 Jun 2021 17:11:58 -0400 In-Reply-To: References: <20200713003002.bs5hwv4gav6ml5rt@bouanto-laptop.localdomain> <874ki6txcc.fsf@tromey.com> <20210220221706.ewfq2b3i2mzx4ice@bouanto-desktop.localdomain> <3ae55b5acc33b38c579ac9c293993c29adc55ae9.camel@redhat.com> <597ecec1c91c1176f740796e20432372377aa554.camel@redhat.com> <0f7f2bf386c29efa1403020cbb02bec815ce25fe.camel@zoho.com> <651ead30f4fa016c233c203bd5d3e749273ab92b.camel@redhat.com> <8d782bf220cc81c727f842b21d835b5b991d3a35.camel@zoho.com> <1f12388082367de4e8d2ea8fe802c22efd50c109.camel@redhat.com> <4834aac911b9fc1f58d0e9cea8773775aad2a23e.camel@zoho.com> Content-Type: multipart/mixed; boundary="=-pxhsppbVnTyZk0LwlHpZ" User-Agent: Evolution 3.40.2 MIME-Version: 1.0 X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 21:12:13 -0000 --=-pxhsppbVnTyZk0LwlHpZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok. Here's the patch with the updated subject and with format fixed. Le vendredi 18 juin 2021 =C3=A0 16:54 -0400, David Malcolm a =C3=A9crit=C2= =A0: > On Fri, 2021-06-18 at 16:42 -0400, Antoni Boucher wrote: > > I'm sending the patch once again for review. > >=20 > > As it's the first time I'll land a patch, I'm not sure what needs > > to be > > done when it's approved. > > Do I just commit it to the master branch directly? >=20 > Commit (and push), yes, but... >=20 > Please ensure the subject line of the commit matches our policy: >=20 > "libgccjit: Handle truncation and extension for casts [PR95498]" >=20 > is a good subject, whereas: >=20 > "This patch handles truncation and extension for casts in jit." >=20 > is not. >=20 > We have some hooks that will only accept pushes if the commit message > has a correctly formatted ChangeLog.=C2=A0 The hooks ought to also add > notification comments to bugzilla for any bugs mentioned in the > commit > message. >=20 > See https://gcc.gnu.org/gitwrite.html#checkin >=20 >=20 > FWIW in my own workflow I have a writable working copy that I keep > for > just doing pushes;=C2=A0 > I do a > =C2=A0 git pull > verify the build, then > =C2=A0 git am FOO.patch --ignore-date > to apply the patch that was tested and approved, then do a last test > with that, then > =C2=A0 git push >=20 > That way I only push the patches that I've tested and have been > approved, and the other ones are in an entirely separate working > copy. > This may be overkill though. >=20 > I'm also on #gcc IRC right now on OFTC (dmalcolm) if you run into > issues. >=20 > Dave >=20 > >=20 > > Thanks! > >=20 > > Le vendredi 11 juin 2021 =C3=A0 13:49 -0400, David Malcolm a =C3=A9crit= =C2=A0: > > > On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote: > > > > Here's the patch with the condition removed. > > > > I believe everything is now fixed. > > > > Thanks! > > >=20 > > > Thanks; this looks good to me.=C2=A0 Is this the latest version of th= e > > > patch; would you like me to apply it? > > >=20 > > > Dave > > >=20 > > > >=20 > > > > Le jeudi 27 mai 2021 =C3=A0 18:21 -0400, David Malcolm a =C3=A9crit= =C2=A0: > > > > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote: > > > > > > I updated the patch according to the comments by Tom > > > > > > Tromey. > > > > > >=20 > > > > > > There's one question left about your question regarding > > > > > > C_MAYBE_CONST_EXPR, David: > > > > > >=20 > > > > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from > > > > > > libgccjit, > > > > > > and > > > > > > it > > > > > > indeed seems like it's only created in c-family. > > > > > > However, we do use it in libgccjit here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playb= ack.c#L1180 > > > > > >=20 > > > > > > I tried removing the condition `if (TREE_CODE (t_ret) !=3D > > > > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still > > > > > > pass. > > > > > >=20 > > > > > > That code was copied from here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c= #L175 > > > > > > and might not be needed in libgccjit. > > > > > >=20 > > > > > > Should I just remove the condition, then? > > > > >=20 > > > > > I think so. > > > > >=20 > > > > > Thanks > > > > > Dave > > > > >=20 > > > > > >=20 > > > > > > Le jeudi 13 mai 2021 =C3=A0 19:58 -0400, David Malcolm a =C3=A9= crit=C2=A0: > > > > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote: > > > > > > > > Thanks for your answer. > > > > > > > >=20 > > > > > > > > See my answers below: > > > > > > > >=20 > > > > > > > > Le jeudi 13 mai 2021 =C3=A0 18:13 -0400, David Malcolm a > > > > > > > > =C3=A9crit=C2=A0: > > > > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via > > > > > > > > > Gcc- > > > > > > > > > patches > > > > > > > > > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Thanks for your feedback! > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Sorry about the delay in responding. > > > > > > > > >=20 > > > > > > > > > In the past I was hesitant about adding more cast > > > > > > > > > support > > > > > > > > > to > > > > > > > > > libgccjit > > > > > > > > > since I felt that the user could always just create a > > > > > > > > > union > > > > > > > > > to > > > > > > > > > do > > > > > > > > > the > > > > > > > > > cast.=C2=A0 Then I tried actually using the libgccjit API > > > > > > > > > to > > > > > > > > > do > > > > > > > > > this, > > > > > > > > > and > > > > > > > > > realized how much work it adds, so I now think we do > > > > > > > > > want > > > > > > > > > to > > > > > > > > > support > > > > > > > > > casting more types. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > See answers below: > > > > > > > > > >=20 > > > > > > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom > > > > > > > > > > Tromey > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > "Antoni" =3D=3D Antoni Boucher via Gcc- > > > > > > > > > > > > > > > > patches > > > > > > > > > > > > > > > > <=C2=A0=C2=A0=20 > > > > > > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes: > > > > > > > > > > >=20 > > > > > > > > > > > Antoni> gcc/jit/ > > > > > > > > > > > Antoni>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0PR target/95498 > > > > > > > > > > > Antoni>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* jit-playback.c: Add support to > > > > > > > > > > > handle > > > > > > > > > > > truncation > > > > > > > > > > > and extension > > > > > > > > > > > Antoni>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0in the convert function. > > > > > > > > > > >=20 > > > > > > > > > > > Antoni> +=C2=A0 switch (dst_code) > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0 { > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0 case INTEGER_TYPE: > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0 case ENUMERAL_TYPE: > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 t_ret =3D con= vert_to_integer > > > > > > > > > > > (dst_type, > > > > > > > > > > > expr); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto maybe_fo= ld; > > > > > > > > > > > Antoni> + > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0 default: > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gcc_assert > > > > > > > > > > > (gcc::jit::active_playback_ctxt); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gcc::jit::act= ive_playback_ctxt- > > > > > > > > > > > > add_error > > > > > > > > > > > (NULL, > > > > > > > > > > > "unhandled conversion"); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fprintf (stde= rr, "input > > > > > > > > > > > expression:\n"); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 debug_tree (e= xpr); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fprintf (stde= rr, "requested > > > > > > > > > > > type:\n"); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 debug_tree (d= st_type); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return error_= mark_node; > > > > > > > > > > > Antoni> + > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0 maybe_fold: > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (TREE_CODE= (t_ret) !=3D > > > > > > > > > > > C_MAYBE_CONST_EXPR) > > > > > > > > >=20 > > > > > > > > > Do we even get C_MAYBE_CONST_EXPR in libgccjit?=C2=A0 Tha= t > > > > > > > > > tree > > > > > > > > > code > > > > > > > > > is > > > > > > > > > defined in c-family/c-common.def; how can nodes of > > > > > > > > > that > > > > > > > > > kind > > > > > > > > > be > > > > > > > > > created > > > > > > > > > outside of the c-family? > > > > > > > >=20 > > > > > > > > I am not sure, but that seems like it's only created in > > > > > > > > c- > > > > > > > > family > > > > > > > > indeed. > > > > > > > > However, we do use it in libgccjit here: > > > > > > > >=20 > > > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-p= layback.c#L1180 > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0t_= ret =3D fold (t_ret); > > > > > > > > > > > Antoni> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return t_ret; > > > > > > > > > > >=20 > > > > > > > > > > > It seems weird to have a single 'goto' to > > > > > > > > > > > maybe_fold, > > > > > > > > > > > especially > > > > > > > > > > > inside > > > > > > > > > > > a switch like this. > > > > > > > > > > >=20 > > > > > > > > > > > If you think the maybe_fold code won't be reused, > > > > > > > > > > > then > > > > > > > > > > > it > > > > > > > > > > > should > > > > > > > > > > > just > > > > > > > > > > > be > > > > > > > > > > > hoisted up and the 'goto' removed. > > > > > > > > > >=20 > > > > > > > > > > This actually depends on how the support for cast > > > > > > > > > > between > > > > > > > > > > integers > > > > > > > > > > and=20 > > > > > > > > > > pointers will be implemented (see below). > > > > > > > > > > If we will support truncating pointers (does that > > > > > > > > > > even > > > > > > > > > > make > > > > > > > > > > sense? > > > > > > > > > > and > > > > > > > > > > I=20 > > > > > > > > > > guess we cannot extend a pointer unless we add the > > > > > > > > > > support > > > > > > > > > > for=20 > > > > > > > > > > uint128_t), that label will be reused for that > > > > > > > > > > case. > > > > > > > > > > Otherwise, it might not be reused. > > > > > > > > > >=20 > > > > > > > > > > So, please tell me which option to choose and I'll > > > > > > > > > > update > > > > > > > > > > my > > > > > > > > > > patch. > > > > > > > > >=20 > > > > > > > > > FWIW I don't think we'll want to support truncating > > > > > > > > > or > > > > > > > > > extending > > > > > > > > > pointers. > > > > > > > >=20 > > > > > > > > Ok, but do you think we'll want to support casts > > > > > > > > between > > > > > > > > integers > > > > > > > > and > > > > > > > > pointers? > > > > > > >=20 > > > > > > > Yes, though we probably want to reject truncating a > > > > > > > pointer > > > > > > > into > > > > > > > a > > > > > > > smaller integer type. > > > > > > >=20 > > > > > > > > I opened an issue about this > > > > > > > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95438) > > > > > > > > and > > > > > > > > would > > > > > > > > be > > > > > > > > willing to do a patch for it eventually. > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > > On the other hand, if the maybe_fold code might > > > > > > > > > > > be > > > > > > > > > > > reused > > > > > > > > > > > for > > > > > > > > > > > some > > > > > > > > > > > other > > > > > > > > > > > case, then I suppose I would have the case end > > > > > > > > > > > with > > > > > > > > > > > 'break' > > > > > > > > > > > and > > > > > > > > > > > then > > > > > > > > > > > have this code outside the switch. > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > In another message, you wrote: > > > > > > > > > > >=20 > > > > > > > > > > > Antoni> For your question, the current code > > > > > > > > > > > already > > > > > > > > > > > works > > > > > > > > > > > with > > > > > > > > > > > boolean and > > > > > > > > > > > Antoni> reals and casts between integers and > > > > > > > > > > > pointers > > > > > > > > > > > is > > > > > > > > > > > currently > > > > > > > > > > > not > > > > > > > > > > > Antoni> supported. > > > > > > > > > > >=20 > > > > > > > > > > > I am curious why this wasn't supported.=C2=A0 It seem= s > > > > > > > > > > > like > > > > > > > > > > > something > > > > > > > > > > > that > > > > > > > > > > > one might want to do. > > > > > > > > > >=20 > > > > > > > > > > I have no idea as this is my first contribution to > > > > > > > > > > gcc. > > > > > > > > > > But this would be indeed very useful and I opened > > > > > > > > > > an > > > > > > > > > > issue > > > > > > > > > > about > > > > > > > > > > this:=20 > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95438 > > > > > > > > > >=20 > > > > > > > > > > > thanks, > > > > > > > > > > > Tom > > > > > > > > > >=20 > > > > > > > > > > Thanks! > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 --=-pxhsppbVnTyZk0LwlHpZ Content-Disposition: attachment; filename*0=0001-libgccjit-Handle-truncation-and-extension-for-casts-.pat; filename*1=ch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="0001-libgccjit-Handle-truncation-and-extension-for-casts-.patch"; charset="UTF-8" RnJvbSBjNjIzNWMzNTM2NDg4NmU5NTM3NjcwMjI0MGFkMjE3MTA2OTY5YjU4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRvbmkgQm91Y2hlciA8Ym91YW50b0B6b2hvLmNvbT4KRGF0 ZTogU3VuLCA1IEp1bCAyMDIwIDE5OjA3OjMwIC0wNDAwClN1YmplY3Q6IFtQQVRDSF0gbGliZ2Nj aml0OiBIYW5kbGUgdHJ1bmNhdGlvbiBhbmQgZXh0ZW5zaW9uIGZvciBjYXN0cwogW1BSOTU0OThd CgoyMDIwLTA3LTEyICBBbnRvbmkgQm91Y2hlciAgPGJvdWFudG9Aem9oby5jb20+CgpnY2Mvaml0 LwoJUFIgdGFyZ2V0Lzk1NDk4CgkqIGppdC1wbGF5YmFjay5jIChjb252ZXJ0KTogQWRkIHN1cHBv cnQgdG8gaGFuZGxlIHRydW5jYXRpb24gYW5kCglleHRlbnNpb24gaW4gdGhlIGNvbnZlcnQgZnVu Y3Rpb24uCgpnY2MvdGVzdHN1aXRlLwoJUFIgdGFyZ2V0Lzk1NDk4CgkqIGppdC5kZy9hbGwtbm9u LWZhaWxpbmctdGVzdHMuaDogTmV3IHRlc3QuCgkqIGppdC5kZy90ZXN0LWNhc3QuYzogTmV3IHRl c3QuCgpTaWduZWQtb2ZmLWJ5OiBBbnRvbmkgQm91Y2hlciA8Ym91YW50b0B6b2hvLmNvbT4KLS0t CiBnY2Mvaml0L2ppdC1wbGF5YmFjay5jICAgICAgICAgICAgICAgICAgICAgICB8IDMzICsrKysr Ky0tLS0KIGdjYy90ZXN0c3VpdGUvaml0LmRnL2FsbC1ub24tZmFpbGluZy10ZXN0cy5oIHwgMTAg KysrCiBnY2MvdGVzdHN1aXRlL2ppdC5kZy90ZXN0LWNhc3QuYyAgICAgICAgICAgICB8IDY2ICsr KysrKysrKysrKysrKysrKysrCiAzIGZpbGVzIGNoYW5nZWQsIDk4IGluc2VydGlvbnMoKyksIDEx IGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGdjYy90ZXN0c3VpdGUvaml0LmRnL3Rl c3QtY2FzdC5jCgpkaWZmIC0tZ2l0IGEvZ2NjL2ppdC9qaXQtcGxheWJhY2suYyBiL2djYy9qaXQv aml0LXBsYXliYWNrLmMKaW5kZXggYzYxMzYzMDEyNDMuLmQyNmYwOGJmYzFiIDEwMDY0NAotLS0g YS9nY2Mvaml0L2ppdC1wbGF5YmFjay5jCisrKyBiL2djYy9qaXQvaml0LXBsYXliYWNrLmMKQEAg LTYyLDIyICs2MiwzMyBAQCBhbG9uZyB3aXRoIEdDQzsgc2VlIHRoZSBmaWxlIENPUFlJTkczLiAg SWYgbm90IHNlZQogCiAvKiBnY2M6OmppdDo6cGxheWJhY2s6OmNvbnRleHQ6OmJ1aWxkX2Nhc3Qg dXNlcyB0aGUgY29udmVydC5oIEFQSSwKICAgIHdoaWNoIGluIHR1cm4gcmVxdWlyZXMgdGhlIGZy b250ZW5kIHRvIHByb3ZpZGUgYSAiY29udmVydCIKLSAgIGZ1bmN0aW9uLCBhcHBhcmVudGx5IGFz IGEgZmFsbGJhY2suCi0KLSAgIEhlbmNlIHdlIHByb3ZpZGUgdGhpcyBkdW1teSBvbmUsIHdpdGgg dGhlIHJlcXVpcmVtZW50IHRoYXQgYW55IGNhc3RzCi0gICBhcmUgaGFuZGxlZCBiZWZvcmUgcmVh Y2hpbmcgdGhpcy4gICovCisgICBmdW5jdGlvbiwgYXBwYXJlbnRseSBhcyBhIGZhbGxiYWNrIGZv ciBjYXN0cyB0aGF0IGNhbiBiZSBzaW1wbGlmaWVkCisgICAodHJ1bmNhdGlvbiwgZXh0ZW5zaW9u KS4gKi8KIGV4dGVybiB0cmVlIGNvbnZlcnQgKHRyZWUgdHlwZSwgdHJlZSBleHByKTsKIAogdHJl ZQogY29udmVydCAodHJlZSBkc3RfdHlwZSwgdHJlZSBleHByKQogewotICBnY2NfYXNzZXJ0IChn Y2M6OmppdDo6YWN0aXZlX3BsYXliYWNrX2N0eHQpOwotICBnY2M6OmppdDo6YWN0aXZlX3BsYXli YWNrX2N0eHQtPmFkZF9lcnJvciAoTlVMTCwgInVuaGFuZGxlZCBjb252ZXJzaW9uIik7Ci0gIGZw cmludGYgKHN0ZGVyciwgImlucHV0IGV4cHJlc3Npb246XG4iKTsKLSAgZGVidWdfdHJlZSAoZXhw cik7Ci0gIGZwcmludGYgKHN0ZGVyciwgInJlcXVlc3RlZCB0eXBlOlxuIik7Ci0gIGRlYnVnX3Ry ZWUgKGRzdF90eXBlKTsKLSAgcmV0dXJuIGVycm9yX21hcmtfbm9kZTsKKyAgdHJlZSB0X3JldCA9 IE5VTEw7CisgIHRfcmV0ID0gdGFyZ2V0bS5jb252ZXJ0X3RvX3R5cGUgKGRzdF90eXBlLCBleHBy KTsKKyAgaWYgKHRfcmV0KQorICAgICAgcmV0dXJuIHRfcmV0OworICBlbnVtIHRyZWVfY29kZSBk c3RfY29kZSA9IFRSRUVfQ09ERSAoZHN0X3R5cGUpOworICBzd2l0Y2ggKGRzdF9jb2RlKQorICAg IHsKKyAgICBjYXNlIElOVEVHRVJfVFlQRToKKyAgICBjYXNlIEVOVU1FUkFMX1RZUEU6CisgICAg ICByZXR1cm4gZm9sZCAoY29udmVydF90b19pbnRlZ2VyIChkc3RfdHlwZSwgZXhwcikpOworCisg ICAgZGVmYXVsdDoKKyAgICAgIGdjY19hc3NlcnQgKGdjYzo6aml0OjphY3RpdmVfcGxheWJhY2tf Y3R4dCk7CisgICAgICBnY2M6OmppdDo6YWN0aXZlX3BsYXliYWNrX2N0eHQtPmFkZF9lcnJvciAo TlVMTCwgInVuaGFuZGxlZCBjb252ZXJzaW9uIik7CisgICAgICBmcHJpbnRmIChzdGRlcnIsICJp bnB1dCBleHByZXNzaW9uOlxuIik7CisgICAgICBkZWJ1Z190cmVlIChleHByKTsKKyAgICAgIGZw cmludGYgKHN0ZGVyciwgInJlcXVlc3RlZCB0eXBlOlxuIik7CisgICAgICBkZWJ1Z190cmVlIChk c3RfdHlwZSk7CisgICAgICByZXR1cm4gZXJyb3JfbWFya19ub2RlOworICAgIH0KIH0KIAogbmFt ZXNwYWNlIGdjYyB7CmRpZmYgLS1naXQgYS9nY2MvdGVzdHN1aXRlL2ppdC5kZy9hbGwtbm9uLWZh aWxpbmctdGVzdHMuaCBiL2djYy90ZXN0c3VpdGUvaml0LmRnL2FsbC1ub24tZmFpbGluZy10ZXN0 cy5oCmluZGV4IDQyMDJlYjc3OThiLi44NGVmNTRhMDM4NiAxMDA2NDQKLS0tIGEvZ2NjL3Rlc3Rz dWl0ZS9qaXQuZGcvYWxsLW5vbi1mYWlsaW5nLXRlc3RzLmgKKysrIGIvZ2NjL3Rlc3RzdWl0ZS9q aXQuZGcvYWxsLW5vbi1mYWlsaW5nLXRlc3RzLmgKQEAgLTk4LDYgKzk4LDEzIEBACiAjdW5kZWYg Y3JlYXRlX2NvZGUKICN1bmRlZiB2ZXJpZnlfY29kZQogCisvKiB0ZXN0LWNhc3QuYyAqLworI2Rl ZmluZSBjcmVhdGVfY29kZSBjcmVhdGVfY29kZV9jYXN0CisjZGVmaW5lIHZlcmlmeV9jb2RlIHZl cmlmeV9jb2RlX2Nhc3QKKyNpbmNsdWRlICJ0ZXN0LWNhc3QuYyIKKyN1bmRlZiBjcmVhdGVfY29k ZQorI3VuZGVmIHZlcmlmeV9jb2RlCisKIC8qIHRlc3QtY29tcG91bmQtYXNzaWdubWVudC5jICov CiAjZGVmaW5lIGNyZWF0ZV9jb2RlIGNyZWF0ZV9jb2RlX2NvbXBvdW5kX2Fzc2lnbm1lbnQKICNk ZWZpbmUgdmVyaWZ5X2NvZGUgdmVyaWZ5X2NvZGVfY29tcG91bmRfYXNzaWdubWVudApAQCAtMzYx LDYgKzM2OCw5IEBAIGNvbnN0IHN0cnVjdCB0ZXN0Y2FzZSB0ZXN0Y2FzZXNbXSA9IHsKICAgeyJj YWxsaW5nX2ludGVybmFsX2Z1bmN0aW9uIiwKICAgIGNyZWF0ZV9jb2RlX2NhbGxpbmdfaW50ZXJu YWxfZnVuY3Rpb24sCiAgICB2ZXJpZnlfY29kZV9jYWxsaW5nX2ludGVybmFsX2Z1bmN0aW9ufSwK KyAgeyJjYXN0IiwKKyAgIGNyZWF0ZV9jb2RlX2Nhc3QsCisgICB2ZXJpZnlfY29kZV9jYXN0fSwK ICAgeyJjb21wb3VuZF9hc3NpZ25tZW50IiwKICAgIGNyZWF0ZV9jb2RlX2NvbXBvdW5kX2Fzc2ln bm1lbnQsCiAgICB2ZXJpZnlfY29kZV9jb21wb3VuZF9hc3NpZ25tZW50fSwKZGlmZiAtLWdpdCBh L2djYy90ZXN0c3VpdGUvaml0LmRnL3Rlc3QtY2FzdC5jIGIvZ2NjL3Rlc3RzdWl0ZS9qaXQuZGcv dGVzdC1jYXN0LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAuLjJiMWUz ODVhZTQwCi0tLSAvZGV2L251bGwKKysrIGIvZ2NjL3Rlc3RzdWl0ZS9qaXQuZGcvdGVzdC1jYXN0 LmMKQEAgLTAsMCArMSw2NiBAQAorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGlv Lmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisKKyNpbmNsdWRlICJsaWJnY2NqaXQuaCIKKworI2lu Y2x1ZGUgImhhcm5lc3MuaCIKKwordm9pZAorY3JlYXRlX2NvZGUgKGdjY19qaXRfY29udGV4dCAq Y3R4dCwgdm9pZCAqdXNlcl9kYXRhKQoreworICAvKiBMZXQncyB0cnkgdG8gaW5qZWN0IHRoZSBl cXVpdmFsZW50IG9mOgorY2hhcgorbXlfY2FzdHMgKGludCB4KQoreworICAgcmV0dXJuIChjaGFy KShsb25nKSB4OworfQorICAgKi8KKyAgZ2NjX2ppdF90eXBlICppbnRfdHlwZSA9CisgICAgZ2Nj X2ppdF9jb250ZXh0X2dldF90eXBlIChjdHh0LCBHQ0NfSklUX1RZUEVfSU5UKTsKKyAgZ2NjX2pp dF90eXBlICpsb25nX3R5cGUgPQorICAgIGdjY19qaXRfY29udGV4dF9nZXRfdHlwZSAoY3R4dCwg R0NDX0pJVF9UWVBFX0xPTkcpOworICBnY2Nfaml0X3R5cGUgKnJldHVybl90eXBlID0KKyAgICBn Y2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUgKGN0eHQsIEdDQ19KSVRfVFlQRV9DSEFSKTsKKworICBn Y2Nfaml0X3BhcmFtICp4ID0KKyAgICBnY2Nfaml0X2NvbnRleHRfbmV3X3BhcmFtICgKKyAgICAg IGN0eHQsCisgICAgICBOVUxMLAorICAgICAgaW50X3R5cGUsICJ4Iik7CisgIGdjY19qaXRfcGFy YW0gKnBhcmFtc1sxXSA9IHt4fTsKKyAgZ2NjX2ppdF9mdW5jdGlvbiAqZnVuYyA9CisgICAgZ2Nj X2ppdF9jb250ZXh0X25ld19mdW5jdGlvbiAoY3R4dCwKKwkJCQkgIE5VTEwsCisJCQkJICBHQ0Nf SklUX0ZVTkNUSU9OX0VYUE9SVEVELAorCQkJCSAgcmV0dXJuX3R5cGUsCisJCQkJICAibXlfY2Fz dHMiLAorCQkJCSAgMSwgcGFyYW1zLCAwKTsKKworICBnY2Nfaml0X2Jsb2NrICppbml0aWFsID0K KyAgICBnY2Nfaml0X2Z1bmN0aW9uX25ld19ibG9jayAoZnVuYywgImluaXRpYWwiKTsKKworICBn Y2Nfaml0X2Jsb2NrX2VuZF93aXRoX3JldHVybihpbml0aWFsLCBOVUxMLAorICAgIGdjY19qaXRf Y29udGV4dF9uZXdfY2FzdChjdHh0LAorICAgICAgICBOVUxMLAorICAgICAgICBnY2Nfaml0X2Nv bnRleHRfbmV3X2Nhc3QoY3R4dCwKKyAgICAgICAgICAgIE5VTEwsCisgICAgICAgICAgICBnY2Nf aml0X3BhcmFtX2FzX3J2YWx1ZSh4KSwKKyAgICAgICAgICAgIGxvbmdfdHlwZQorICAgICAgICAp LAorICAgICAgICByZXR1cm5fdHlwZQorICAgICkpOworfQorCit2b2lkCit2ZXJpZnlfY29kZSAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X3Jlc3VsdCAqcmVzdWx0KQoreworICB0eXBl ZGVmIGludCAoKm15X2Nhc3RzX2ZuX3R5cGUpIChpbnQpOworICBDSEVDS19OT05fTlVMTCAocmVz dWx0KTsKKyAgbXlfY2FzdHNfZm5fdHlwZSBteV9jYXN0cyA9CisgICAgKG15X2Nhc3RzX2ZuX3R5 cGUpZ2NjX2ppdF9yZXN1bHRfZ2V0X2NvZGUgKHJlc3VsdCwgIm15X2Nhc3RzIik7CisgIENIRUNL X05PTl9OVUxMIChteV9jYXN0cyk7CisgIGNoYXIgdmFsID0gbXlfY2FzdHMgKDEwKTsKKyAgbm90 ZSAoIm15X2Nhc3RzIHJldHVybmVkOiAlZCIsIHZhbCk7CisgIENIRUNLX1ZBTFVFICh2YWwsIDEw KTsKK30KLS0gCjIuMzIuMAoK --=-pxhsppbVnTyZk0LwlHpZ--