From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27787 invoked by alias); 27 Jul 2019 06:16:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27779 invoked by uid 89); 27 Jul 2019 06:16:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=operate, builtins.c, UD:builtins.c, Implementing X-HELO: mail-ed1-f65.google.com Received: from mail-ed1-f65.google.com (HELO mail-ed1-f65.google.com) (209.85.208.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 27 Jul 2019 06:16:32 +0000 Received: by mail-ed1-f65.google.com with SMTP id i11so54992576edq.0 for ; Fri, 26 Jul 2019 23:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LOKI+qSLgJ3V59TY9CydUJIcNc0pouM/wkbcSCAqVXI=; b=OHhZzy9DGXbmNbYJTSEZSwTY+nkEE6QPy2DMwqZDtQfCLjIa7MdqtVPL6h70FW5WWb TnP3D9MQ69urFq9JG//rFL0WFlLe8GNO9/f+gtSGChQ9qrAh0EYld/8NHg6Vxb9KcaR+ HY4+u7Q4gco0s08M6QHu+X+NPlzmRYWvi2jegh1AJMEx0D2oHnVtWsjEGxXn2M/C1NtU 2ace7qKFS1LauUhfA0OO2anyYHZ3ytXV7IvGIvFqaZxohYohOi+gJy3l5GFt3aDQ3VPx jrVmsj6vq/4UxO6zF6kxObywpuKiBE/xrFxl7fqtQrVl5vcCTG3qMxSZcrpdBSIlrz/3 0j3A== MIME-Version: 1.0 References: In-Reply-To: From: Tejas Joshi Date: Sat, 27 Jul 2019 06:16:00 -0000 Message-ID: Subject: Re: [GSoC-19] Implementing narrowing functions like fadd To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com Content-Type: multipart/mixed; boundary="00000000000084d8d5058ea3991b" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00178.txt.bz2 --00000000000084d8d5058ea3991b Content-Type: text/plain; charset="UTF-8" Content-length: 7034 Hello. >> You'll need something different from CASE_MATHFN - these are a different >> kind of functions that need handling in a different way, because they are >> parametrized over certain *pairs* of types, rather than over a single >> type. > first phase, please just directly test for in the code for > CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process > those here to get a prototype working. When you add support for more Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this following patch and function is getting folded. My question is that how the addition and narrowing should be performed (is it ok to use do_add for addition?). As functions in real.c does not operate on any specific precision, just defining the return type as float would do the trick? Or do I need to make trailing out-of-precision bits zero? If yes, having functions like double_to_float would then be useful or such functions already exist to do the conversion? Thanks, Tejas On Fri, 26 Jul 2019 at 22:49, Martin Jambor wrote: > > Hello Tejas, > > On Tue, Jul 23 2019, Tejas Joshi wrote: > > Hi all, > > I have some doubts regarding narrowing functions. Functions like fadd > > have different variants like fadd, faddl and daddl. These functions > > differs from general floating point functions which have float and > > long double argument types. These functions are defined in > > builtins.def like floor, floorf and floorl with their respective > > macros BUILT_IN_FLOOR, BUILT_IN_FLOORF and BUILT_IN_FLOORL. But for > > fadd, fsub, fmul variants, float is not supposed to be one of the > > argument types. > > > > Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand > > normal, F and L variants which are assigned to respective fcode > > built_in_function. This makes any function defined in builtins.def to > > have F and L variants mandatory. How these narrowing functions are > > supposed to be handled? Do we define another macro expansion like > > CASE_MATHFN or have a manual case handling in mathfn_built_in_2? > > Attached patch is what I have tried so far. > > They are different so as Joseph pointed out, they need to be handled > differently, don't feel too constrained by the patterns already in gcc. > For now you can even just just use directly the constants > CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL in the code to > get a prototype working and then set out to create a macro to wrap this > in, perhaps even only after you added support for two or more such > narrowing instructions so that you see how the common parts look like. > > > > diff --git a/gcc/builtins.c b/gcc/builtins.c > > index 8ceb077b0bf..37c4206ec65 100644 > > --- a/gcc/builtins.c > > +++ b/gcc/builtins.c > > @@ -2006,6 +2006,7 @@ mathfn_built_in_2 (tree type, combined_fn fn) > > CASE_MATHFN (EXP2) > > CASE_MATHFN (EXPM1) > > CASE_MATHFN (FABS) > > + CASE_MATHFN (FADD) > > CASE_MATHFN (FDIM) > > CASE_MATHFN_FLOATN (FLOOR) > > CASE_MATHFN_FLOATN (FMA) > > This does not seem to be necessary for folding, or am I wrong? If it is > intended for expansion, I'd drop it from this patch and move to the one > where it is required. > > > > > diff --git a/gcc/builtins.def b/gcc/builtins.def > > index 8bb7027aac7..2e749f038be 100644 > > --- a/gcc/builtins.def > > +++ b/gcc/builtins.def > > @@ -352,6 +352,12 @@ DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT > > #define FABS_TYPE(F) BT_FN_##F##_##F > > DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST) > > #undef FABS_TYPE > > +DEF_EXT_LIB_BUILTIN (BUILT_IN_FADD, "fadd", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST) > > +DEF_EXT_LIB_BUILTIN (BUILT_IN_DADDL, "daddl", BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST) > > +DEF_EXT_LIB_BUILTIN (BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST) > > +#define FADD_TYPE(F) BT_FN_##F##_##F##_##F > > +DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FADD, "fadd", FADD_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST) > > +#undef FADD_TYPE > > This results into definitions like BUILT_IN_FADDF32 (what would that > do?) and BUILT_IN_FADDF64 or BUILT_IN_FADDF128 (which I don't think we > want, Joseph?). Perhaps you can just simply drop this use of > DEF_EXT_LIB_FLOATN_NX_BUILTINS? > > > DEF_GCC_BUILTIN (BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST) > > DEF_GCC_BUILTIN (BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST) > > DEF_GCC_BUILTIN (BUILT_IN_FABSD128, "fabsd128", BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST) > > diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c > > index d9b546e6803..9f0e5510514 100644 > > --- a/gcc/fold-const-call.c > > +++ b/gcc/fold-const-call.c > > @@ -570,6 +570,16 @@ fold_const_nextafter (real_value *result, const real_value *arg0, > > return true; > > } > > > > +static bool > > +fold_const_fadd (real_value* result, const real_value *arg0, > > + const real_value *arg1, const real_format *format) > > +{ > > + if (!real_fadd(result, format, arg0, arg1)) > > + return true; > > + else > > + return false; > > +} > > + > > /* Try to evaluate: > > > > *RESULT = ldexp (*ARG0, ARG1) > > @@ -1366,6 +1376,9 @@ fold_const_call_sss (real_value *result, combined_fn fn, > > CASE_CFN_NEXTTOWARD: > > return fold_const_nextafter (result, arg0, arg1, format); > > > > + CASE_CFN_FADD: > > + return fold_const_fadd (result, arg0, arg1, format); > > + > > As you have pointed out, this does not work, this is not expanded into a > macro and is just as an unused label for which you get a warning. > Moreover... > > > default: > > return false; > > } > > @@ -1500,6 +1513,20 @@ fold_const_call_1 (combined_fn fn, tree type, tree arg0, tree arg1) > > } > > return NULL_TREE; > > } > > + else if (mode != arg0_mode > > + && real_cst_p (arg0) > > + && real_cst_p (arg1)) > > + { > > + gcc_checking_assert (SCALAR_FLOAT_MODE_P (arg0_mode)); > > + REAL_VALUE_TYPE result; > > + if (arg0_mode == arg1_mode) > > + { > > + if (fold_const_call_sss (&result, fn, TREE_REAL_CST_PTR (arg0), > > + TREE_REAL_CST_PTR (arg1), > > + REAL_MODE_FORMAT (mode))) > > ...I don't think you want to stuff handling narrowing functions into > fold_const_call_sss, that is for operations with matching type. In the > first phase, please just directly test for in the code for > CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process > those here to get a prototype working. When you add support for more > narrowing functions we can then move their processing into a new > separate function. > > At leat that is how I would proceed with folding. > > Thanks, > > Martin --00000000000084d8d5058ea3991b Content-Type: text/x-patch; charset="US-ASCII"; name="fadd-1.diff" Content-Disposition: attachment; filename="fadd-1.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jyl59kej0 Content-length: 6174 ZGlmZiAtLWdpdCBhL2djYy9idWlsdGluLXR5cGVzLmRlZiBiL2djYy9idWls dGluLXR5cGVzLmRlZgppbmRleCBlNWM5ZTA2M2M0OC4uNmJjNTUyZmE3MWEg MTAwNjQ0Ci0tLSBhL2djYy9idWlsdGluLXR5cGVzLmRlZgorKysgYi9nY2Mv YnVpbHRpbi10eXBlcy5kZWYKQEAgLTM4Nyw4ICszODcsMTQgQEAgREVGX0ZV TkNUSU9OX1RZUEVfMiAoQlRfRk5fVk9JRF9VSU5UX1BUUiwKIAkJICAgICBC VF9WT0lELCBCVF9VSU5ULCBCVF9QVFIpCiBERUZfRlVOQ1RJT05fVFlQRV8y IChCVF9GTl9GTE9BVF9GTE9BVF9GTE9BVCwKIAkJICAgICBCVF9GTE9BVCwg QlRfRkxPQVQsIEJUX0ZMT0FUKQorREVGX0ZVTkNUSU9OX1RZUEVfMiAoQlRf Rk5fRkxPQVRfRE9VQkxFX0RPVUJMRSwKKwkJICAgICBCVF9GTE9BVCwgQlRf RE9VQkxFLCBCVF9ET1VCTEUpCitERUZfRlVOQ1RJT05fVFlQRV8yIChCVF9G Tl9GTE9BVF9MT05HRE9VQkxFX0xPTkdET1VCTEUsCisJCSAgICAgQlRfRkxP QVQsIEJUX0xPTkdET1VCTEUsIEJUX0xPTkdET1VCTEUpCiBERUZfRlVOQ1RJ T05fVFlQRV8yIChCVF9GTl9ET1VCTEVfRE9VQkxFX0RPVUJMRSwKIAkJICAg ICBCVF9ET1VCTEUsIEJUX0RPVUJMRSwgQlRfRE9VQkxFKQorREVGX0ZVTkNU SU9OX1RZUEVfMiAoQlRfRk5fRE9VQkxFX0xPTkdET1VCTEVfTE9OR0RPVUJM RSwKKwkJICAgICBCVF9ET1VCTEUsIEJUX0xPTkdET1VCTEUsIEJUX0xPTkdE T1VCTEUpCiBERUZfRlVOQ1RJT05fVFlQRV8yIChCVF9GTl9MT05HRE9VQkxF X0xPTkdET1VCTEVfTE9OR0RPVUJMRSwKIAkJICAgICBCVF9MT05HRE9VQkxF LCBCVF9MT05HRE9VQkxFLCBCVF9MT05HRE9VQkxFKQogREVGX0ZVTkNUSU9O X1RZUEVfMiAoQlRfRk5fRkxPQVQxNl9GTE9BVDE2X0ZMT0FUMTYsCmRpZmYg LS1naXQgYS9nY2MvYnVpbHRpbnMuZGVmIGIvZ2NjL2J1aWx0aW5zLmRlZgpp bmRleCA4YmI3MDI3YWFjNy4uMmRmNjE2YzQ3N2UgMTAwNjQ0Ci0tLSBhL2dj Yy9idWlsdGlucy5kZWYKKysrIGIvZ2NjL2J1aWx0aW5zLmRlZgpAQCAtMzU1 LDYgKzM1NSw5IEBAIERFRl9FWFRfTElCX0ZMT0FUTl9OWF9CVUlMVElOUyAo QlVJTFRfSU5fRkFCUywgImZhYnMiLCBGQUJTX1RZUEUsIEFUVFJfQ09OU1Rf Tk9UCiBERUZfR0NDX0JVSUxUSU4gICAgICAgIChCVUlMVF9JTl9GQUJTRDMy LCAiZmFic2QzMiIsIEJUX0ZOX0RGTE9BVDMyX0RGTE9BVDMyLCBBVFRSX0NP TlNUX05PVEhST1dfTEVBRl9MSVNUKQogREVGX0dDQ19CVUlMVElOICAgICAg ICAoQlVJTFRfSU5fRkFCU0Q2NCwgImZhYnNkNjQiLCBCVF9GTl9ERkxPQVQ2 NF9ERkxPQVQ2NCwgQVRUUl9DT05TVF9OT1RIUk9XX0xFQUZfTElTVCkKIERF Rl9HQ0NfQlVJTFRJTiAgICAgICAgKEJVSUxUX0lOX0ZBQlNEMTI4LCAiZmFi c2QxMjgiLCBCVF9GTl9ERkxPQVQxMjhfREZMT0FUMTI4LCBBVFRSX0NPTlNU X05PVEhST1dfTEVBRl9MSVNUKQorREVGX0VYVF9MSUJfQlVJTFRJTiAgICAo QlVJTFRfSU5fRkFERCwgImZhZGQiLCBCVF9GTl9GTE9BVF9ET1VCTEVfRE9V QkxFLCBBVFRSX0NPTlNUX05PVEhST1dfTEVBRl9MSVNUKQorREVGX0VYVF9M SUJfQlVJTFRJTiAgICAoQlVJTFRfSU5fRkFEREwsICJmYWRkbCIsIEJUX0ZO X0ZMT0FUX0xPTkdET1VCTEVfTE9OR0RPVUJMRSwgQVRUUl9DT05TVF9OT1RI Uk9XX0xFQUZfTElTVCkKK0RFRl9FWFRfTElCX0JVSUxUSU4gICAgKEJVSUxU X0lOX0RBRERMLCAiZGFkZGwiLCBCVF9GTl9ET1VCTEVfTE9OR0RPVUJMRV9M T05HRE9VQkxFLCBBVFRSX0NPTlNUX05PVEhST1dfTEVBRl9MSVNUKQogREVG X0M5OV9CVUlMVElOICAgICAgICAoQlVJTFRfSU5fRkRJTSwgImZkaW0iLCBC VF9GTl9ET1VCTEVfRE9VQkxFX0RPVUJMRSwgQVRUUl9NQVRIRk5fRlBST1VO RElOR19FUlJOTykKIERFRl9DOTlfQlVJTFRJTiAgICAgICAgKEJVSUxUX0lO X0ZESU1GLCAiZmRpbWYiLCBCVF9GTl9GTE9BVF9GTE9BVF9GTE9BVCwgQVRU Ul9NQVRIRk5fRlBST1VORElOR19FUlJOTykKIERFRl9DOTlfQlVJTFRJTiAg ICAgICAgKEJVSUxUX0lOX0ZESU1MLCAiZmRpbWwiLCBCVF9GTl9MT05HRE9V QkxFX0xPTkdET1VCTEVfTE9OR0RPVUJMRSwgQVRUUl9NQVRIRk5fRlBST1VO RElOR19FUlJOTykKZGlmZiAtLWdpdCBhL2djYy9mb2xkLWNvbnN0LWNhbGwu YyBiL2djYy9mb2xkLWNvbnN0LWNhbGwuYwppbmRleCBkOWI1NDZlNjgwMy4u Mzc0ZmU1MTdiZDYgMTAwNjQ0Ci0tLSBhL2djYy9mb2xkLWNvbnN0LWNhbGwu YworKysgYi9nY2MvZm9sZC1jb25zdC1jYWxsLmMKQEAgLTU3MCw2ICs1NzAs MTYgQEAgZm9sZF9jb25zdF9uZXh0YWZ0ZXIgKHJlYWxfdmFsdWUgKnJlc3Vs dCwgY29uc3QgcmVhbF92YWx1ZSAqYXJnMCwKICAgcmV0dXJuIHRydWU7CiB9 CiAKK3N0YXRpYyBib29sCitmb2xkX2NvbnN0X2ZhZGQgKHJlYWxfdmFsdWUq IHJlc3VsdCwgY29uc3QgcmVhbF92YWx1ZSAqYXJnMCwKKwkJIGNvbnN0IHJl YWxfdmFsdWUgKmFyZzEsIGNvbnN0IHJlYWxfZm9ybWF0ICpmb3JtYXQpCit7 CisgIGlmICghcmVhbF9mYWRkKHJlc3VsdCwgZm9ybWF0LCBhcmcwLCBhcmcx KSkKKyAgICByZXR1cm4gdHJ1ZTsKKyAgZWxzZQorICAgIHJldHVybiBmYWxz ZTsKK30KKwogLyogVHJ5IHRvIGV2YWx1YXRlOgogCiAgICAgICAqUkVTVUxU ID0gbGRleHAgKCpBUkcwLCBBUkcxKQpAQCAtMTY0NCw2ICsxNjU0LDI1IEBA IGZvbGRfY29uc3RfY2FsbCAoY29tYmluZWRfZm4gZm4sIHRyZWUgdHlwZSwg dHJlZSBhcmcwLCB0cmVlIGFyZzEpCiAgICAgY2FzZSBDRk5fRk9MRF9MRUZU X1BMVVM6CiAgICAgICByZXR1cm4gZm9sZF9jb25zdF9mb2xkX2xlZnQgKHR5 cGUsIGFyZzAsIGFyZzEsIFBMVVNfRVhQUik7CiAKKyAgICBjYXNlIENGTl9C VUlMVF9JTl9GQUREOgorICAgIGNhc2UgQ0ZOX0JVSUxUX0lOX0ZBRERMOgor ICAgIGNhc2UgQ0ZOX0JVSUxUX0lOX0RBRERMOgorICAgICAgeworCWlmIChy ZWFsX2NzdF9wIChhcmcwKQorCSAgICAmJiByZWFsX2NzdF9wIChhcmcxKSkK Kwl7CisJICBtYWNoaW5lX21vZGUgYXJnMF9tb2RlID0gVFlQRV9NT0RFIChU UkVFX1RZUEUgKGFyZzApKTsKKwkgIGdjY19jaGVja2luZ19hc3NlcnQgKFND QUxBUl9GTE9BVF9NT0RFX1AgKGFyZzBfbW9kZSkpOworCSAgUkVBTF9WQUxV RV9UWVBFIHJlc3VsdDsKKwkgIG1hY2hpbmVfbW9kZSBtb2RlID0gVFlQRV9N T0RFICh0eXBlKTsKKwkgIGlmIChmb2xkX2NvbnN0X2ZhZGQgKCZyZXN1bHQs IFRSRUVfUkVBTF9DU1RfUFRSIChhcmcwKSwKKwkJCSAgICAgICBUUkVFX1JF QUxfQ1NUX1BUUiAoYXJnMSksCisJCQkgICAgICAgUkVBTF9NT0RFX0ZPUk1B VCAobW9kZSkpKQorCSAgICByZXR1cm4gYnVpbGRfcmVhbCAodHlwZSwgcmVz dWx0KTsKKwl9CisgICAgICB9CisgICAgICByZXR1cm4gTlVMTF9UUkVFOwor CiAgICAgZGVmYXVsdDoKICAgICAgIHJldHVybiBmb2xkX2NvbnN0X2NhbGxf MSAoZm4sIHR5cGUsIGFyZzAsIGFyZzEpOwogICAgIH0KZGlmZiAtLWdpdCBh L2djYy9yZWFsLmMgYi9nY2MvcmVhbC5jCmluZGV4IGFiNzE0MzA3MDlmLi40 NDRhYjJlMjdmYyAxMDA2NDQKLS0tIGEvZ2NjL3JlYWwuYworKysgYi9nY2Mv cmVhbC5jCkBAIC01MDkzLDYgKzUwOTMsMTYgQEAgcmVhbF9yb3VuZGV2ZW4g KFJFQUxfVkFMVUVfVFlQRSAqciwgZm9ybWF0X2hlbHBlciBmbXQsCiAgICAg cmVhbF9yb3VuZCAociwgZm10LCB4KTsKIH0KIAorYm9vbAorcmVhbF9mYWRk IChSRUFMX1ZBTFVFX1RZUEUgKnIsIGZvcm1hdF9oZWxwZXIgZm10LAorCSAg IGNvbnN0IFJFQUxfVkFMVUVfVFlQRSAqeCwgY29uc3QgUkVBTF9WQUxVRV9U WVBFICp5KQoreworICBkb19hZGQgKHIsIHgsIHksIDApOworICBpZiAoZm10 KQorICAgIHJlYWxfY29udmVydCAociwgZm10LCByKTsKKyAgcmV0dXJuIGZh bHNlOworfQorCiAvKiBTZXQgdGhlIHNpZ24gb2YgUiB0byB0aGUgc2lnbiBv ZiBYLiAgKi8KIAogdm9pZApkaWZmIC0tZ2l0IGEvZ2NjL3JlYWwuaCBiL2dj Yy9yZWFsLmgKaW5kZXggNzY4ODliZmYwZWEuLmY5ZDM4OGY0OTFiIDEwMDY0 NAotLS0gYS9nY2MvcmVhbC5oCisrKyBiL2djYy9yZWFsLmgKQEAgLTUxMCw2 ICs1MTAsMTAgQEAgZXh0ZXJuIHZvaWQgcmVhbF9yb3VuZCAoUkVBTF9WQUxV RV9UWVBFICosIGZvcm1hdF9oZWxwZXIsCiBleHRlcm4gdm9pZCByZWFsX3Jv dW5kZXZlbiAoUkVBTF9WQUxVRV9UWVBFICosIGZvcm1hdF9oZWxwZXIsCiAg ICAgICBjb25zdCBSRUFMX1ZBTFVFX1RZUEUgKik7CiAKKy8qIE5hcnJvd2lu ZyB0eXBlIHN0YW5kYXJkIG1hdGggb3BlcmF0aW9ucyBmdW5jdGlvbnMuICAq LworZXh0ZXJuIGJvb2wgcmVhbF9mYWRkIChSRUFMX1ZBTFVFX1RZUEUgKiwg Zm9ybWF0X2hlbHBlciwKKwljb25zdCBSRUFMX1ZBTFVFX1RZUEUgKiwgY29u c3QgUkVBTF9WQUxVRV9UWVBFICopOworCiAvKiBTZXQgdGhlIHNpZ24gb2Yg UiB0byB0aGUgc2lnbiBvZiBYLiAgKi8KIGV4dGVybiB2b2lkIHJlYWxfY29w eXNpZ24gKFJFQUxfVkFMVUVfVFlQRSAqLCBjb25zdCBSRUFMX1ZBTFVFX1RZ UEUgKik7CiAK --00000000000084d8d5058ea3991b--