USE_QUADMATH build of perl on Win32

--0000000000002090b905b7ce7fa8
Content-Type: text/plain; charset="UTF-8"

Hi,
I'm in the process of hacking up a quadmath build of current blead on
(native) Windows 7.

By patching only win32/GNUmakefile, I've got to the stage where miniperl
has been successfully built without issuing any warnings.
(Actually there's some warnings issued re win32.c, but I'm ignoring them
for the moment as they're also present on double and long double builds.)

As a rough check that miniperl is in fact a quadmath build I can run:
C:\comp\perl-5.33.6-q\win32>..\miniperl.exe -le "print sqrt(2.0);"
1.4142135623730950488016887242097

That's the same output as I get on Ubuntu -Dusequadmath builds ... so all
looks good to that extent.

The problem I'm facing is with the very next step in the build process:
...\miniperl.exe -I..\lib -f ..\write_buildcustomize.pl ..
Invalid version format (negative version number) at dist/constant/lib/
constant.pm line 2.
BEGIN failed--compilation aborted at dist/constant/lib/constant.pm line 2.
Compilation failed in require at dist/PathTools/lib/File/Spec/Unix.pm line
115.
BEGIN failed--compilation aborted at dist/PathTools/lib/File/Spec/Unix.pm
line 115.
Compilation failed in require at dist/PathTools/lib/File/Spec/Win32.pm line
6.
Compilation failed in require at dist/PathTools/lib/File/Spec.pm line 21.
Compilation failed in require at dist/PathTools/lib/File/Spec/Functions.pm
line3.
BEGIN failed--compilation aborted at
dist/PathTools/lib/File/Spec/Functions.pm line 3.
Compilation failed in require at ..\write_buildcustomize.pl line 59.

Line 2 of constant pm is merely "use 5.008;" and the error message comes
from vutil.c.

Apparently miniperl's use() is somehow managing to interpret 5.008 as a -ve
number:
C:\comp\perl-5.33.6-q\win32>..\miniperl.exe -le "use 5.008"
Invalid version format (negative version number) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

If I try to use 5.001 instead, I get a different error (this time from
util.c):
C:\comp\perl-5.33.6-q\win32>..\miniperl.exe -le "use 5.001"
panic: my_snprintf buffer overflow at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

If I try to use() 5, or 5.0, or 5.00, then there's no problem.

On a -Dusequadmath build on Ubuntu I can generate the "negative version
number" error with:
$ perl -le 'require (-5.008);'
Invalid version format (negative version number) at -e line 1.

From that, I deduce that vutil.c is *not* meant to be "out of bounds" for
quadmath builds.

Any ideas on what I need to do next ?
I'll probably work it out eventually, but it could take me a while ;-)
Any hints or thoughts are most welcome.

Cheers,
Rob

--0000000000002090b905b7ce7fa8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div>I&#39;m in the process of hacking up a quadmath bu=
ild of current blead on (native) Windows 7.</div><div><br></div><div>By pat=
ching only win32/GNUmakefile, I&#39;ve got to the stage where miniperl has =
been successfully built without issuing any warnings.</div><div>(Actually t=
here&#39;s some warnings issued re win32.c, but I&#39;m ignoring them for t=
he moment as they&#39;re also present on double and long double builds.)</d=
iv><div><br></div><div>As a rough check that miniperl is in fact a quadmath=
 build I can run:</div><div>C:\comp\perl-5.33.6-q\win32&gt;..\miniperl.exe =
-le &quot;print sqrt(2.0);&quot;<br>1.4142135623730950488016887242097<br></=
div><div><br></div><div>That&#39;s the same output as I get on Ubuntu -Duse=
quadmath builds ... so all looks good to that extent.</div><div><br></div><=
div>The problem I&#39;m facing is with the very next step in the build proc=
ess:</div><div>..\miniperl.exe -I..\lib -f ..\<a href=3D"http://write_build=
customize.pl">write_buildcustomize.pl</a> ..<br>Invalid version format (neg=
ative version number) at dist/constant/lib/<a href=3D"http://constant.pm">c=
onstant.pm</a> line 2.<br></div><div>BEGIN failed--compilation aborted at d=
ist/constant/lib/<a href=3D"http://constant.pm">constant.pm</a> line 2.<br>=
Compilation failed in require at dist/PathTools/lib/File/Spec/Unix.pm line =
115.<br>BEGIN failed--compilation aborted at dist/PathTools/lib/File/Spec/U=
nix.pm line 115.<br>Compilation failed in require at dist/PathTools/lib/Fil=
e/Spec/Win32.pm line 6.<br>Compilation failed in require at dist/PathTools/=
lib/File/Spec.pm line 21.<br>Compilation failed in require at dist/PathTool=
s/lib/File/Spec/Functions.pm line3.<br>BEGIN failed--compilation aborted at=
 dist/PathTools/lib/File/Spec/Functions.pm line 3.<br>Compilation failed in=
 require at ..\<a href=3D"http://write_buildcustomize.pl">write_buildcustom=
ize.pl</a> line 59.<br></div><div><br></div><div>Line 2 of constant pm is m=
erely &quot;use 5.008;&quot; and the error message comes from vutil.c.</div=
><div><br></div><div>Apparently miniperl&#39;s use() is somehow managing to=
 interpret 5.008 as a -ve number:</div><div>C:\comp\perl-5.33.6-q\win32&gt;=
...\miniperl.exe -le &quot;use 5.008&quot;<br>Invalid version format (negati=
ve version number) at -e line 1.<br>BEGIN failed--compilation aborted at -e=
 line 1.<br></div><div><br></div><div>If I try to use 5.001 instead, I get =
a different error (this time from util.c):</div><div>C:\comp\perl-5.33.6-q\=
win32&gt;..\miniperl.exe -le &quot;use 5.001&quot;<br>panic: my_snprintf bu=
ffer overflow at -e line 1.<br>BEGIN failed--compilation aborted at -e line=
 1.<br></div><div><br></div><div>If I try to use() 5, or 5.0, or 5.00, then=
 there&#39;s no problem.</div><div><br></div><div>On a -Dusequadmath build =
on Ubuntu I can generate the &quot;negative version number&quot; error with=
:</div><div>$ perl -le &#39;require (-5.008);&#39;<br>Invalid version forma=
t (negative version number) at -e line 1.<br></div><div><br></div><div>From=
 that, I deduce that vutil.c is *not* meant to be &quot;out of bounds&quot;=
 for quadmath builds.</div><div><br></div><div>Any ideas on what I need=C2=
=A0to do next ?</div><div>I&#39;ll probably work it out eventually, but it =
could take me a while ;-)</div><div>Any hints or thoughts are most welcome.=
</div><div><br></div><div>Cheers,</div><div>Rob</div></div>

--0000000000002090b905b7ce7fa8--
0
sisyphus359
1/1/2021 3:39:46 AM
perl.perl5.porters 48290 articles. 1 followers. Follow

4 Replies
14 Views

Similar Articles

[PageSpeed] 15

sisyphus <sisyphus359@gmail.com> wrote:
[...]
:Any ideas on what I need to do next ?

Can you run the same command under a debugger and set a breakpoint just
before the vutil.c error, to take a look at the string it is parsing?
That would seem like the first critical clue: whether is is (say) "-5.008"
or something totally mangled.

Hugo
0
hv
1/1/2021 3:10:11 PM
--000000000000f6e4bc05b7fef1c1
Content-Type: multipart/alternative; boundary="000000000000f6e4b905b7fef1bf"

--000000000000f6e4b905b7fef1bf
Content-Type: text/plain; charset="UTF-8"

Thanks Jim, Hugo.
I've made some progress in that I can now get the build process to run to
completion.
("use 5.008" was in fact trying to process garbage - because I hadn't
corrected the NVef, NVff and NVgf definitions.)

I know that, with my Math-Float128 module on Windows , the module crashes
perl on loading, unless alignment settings are specified as follows:

#if defined(__MINGW32__) && !defined(__MINGW64__)
typedef __float128 float128 __attribute__ ((aligned(32)));
#elif defined(__MINGW64__) || (defined(DEBUGGING) && defined(NV_IS_DOUBLE))
typedef __float128 float128 __attribute__ ((aligned(8)));
#else
typedef __float128 float128;
#endif

Compilers that are neither mingw.org or mingw-w64 are rejected outright.
The "#if" block applies to the case where the compiler is a 32-bit mingw.org
compiler.
The "#elif" block applies to the case where the compiler is either a 64-bit
mingw-w64 compiler, or a 32-bit mingw compiler (either mingw.org or
mingw-w64) on a debugging build of perl with an nvtype of double.
The"#else" block (where no alteration to byte alignment is needed) applies
to  all other scenarios involving mingw compilers.

When I build my USE_QUADMATH perl-5.33.6 using a 64-bit mingw-w64 compiler
(the "#if" case), the perl that is built crashes on start up. I'm feeling
confident that this happens because the alignment has not been adjusted.
When I build my USE_QUADMATH perl-5.33.6 using a 32-bit mingw-w64 compiler
(the "#else" case), the perl that is built runs without issue.  I'm feeling
confident that this happens because the alignment needs no adjustment.

I've attached 'fail_32_q.txt', which lists the test failures for my 32-bit
USE_QUADMATH build. (Only 5 test files producing failures - pretty chuffed
about that.)
And I've also attached 'V_32_q.txt', which provides the "perl -V" output
for this 32-bit USE_QUADMATH build.
Any constructive comments/observations are *most* welcome.

My questions are:

1) With any working perl on Windows, how do I find out what the byte
alignment is ?
$Config{alignbytes} always reports "8". But I suspect that's just because
that's the value specified in win32/config.gc.
I did try altering that specified value in win32/config.gc, and
$Config{alignbytes} always matched the value that I specified - but I could
see no evidence that the byte alignment was in fact being altered by those
changes.

2) How/where, within the perl source, do I introduce those byte-alignment
alterations  to match the settings I've applied in Math-Float128 ?

For the moment, I'll just concentrate on the 32-bit USE_QUADMATH build, as
it's basically usable.
Solving the test failures there will, hopefully, transfer across to the
64-bit builds once I've sorted out their alignmentl issues

Cheers,
Rob

PS
Thanks for the heads up on the 'make minitest_prep' and 'make minitest'
options, Jim.
There's a problem with ExtUtils-PL2Bat that's currently limiting their
usefulness on windows for this particular exercise.
I hope to fix that eventually, of course - but even so, it's handy to know
of the availability of this stuff on other systems. (I also spend time on
Debian and Ubuntu, these days.)
As for the 20 years you alluded to .... well, they've provided numerous
challenges, plenty of frustrations and lots of egg-on-face moments, but the
overall feeling continues to be one of delight and enjoyment. (No altruism
here - just plain self-indulgence ;-)




On Sat, Jan 2, 2021 at 2:19 AM <hv@crypt.org> wrote:

> sisyphus <sisyphus359@gmail.com> wrote:
> [...]
> :Any ideas on what I need to do next ?
>
> Can you run the same command under a debugger and set a breakpoint just
> before the vutil.c error, to take a look at the string it is parsing?
> That would seem like the first critical clue: whether is is (say) "-5.008"
> or something totally mangled.
>
> Hugo
>

--000000000000f6e4b905b7fef1bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Thanks Jim, Hugo.<div>I&#39;ve made some =
progress in that I can now get the build process to run to completion.</div=
><div>(&quot;use 5.008&quot; was in fact trying to process garbage - becaus=
e I hadn&#39;t corrected the NVef, NVff and NVgf definitions.)</div><div><b=
r></div><div>I know that, with my Math-Float128 module on Windows , the mod=
ule crashes perl on loading, unless alignment settings are specified as fol=
lows:</div><div><br></div><div>#if defined(__MINGW32__) &amp;&amp; !defined=
(__MINGW64__)<br>typedef __float128 float128 __attribute__ ((aligned(32)));=
<br>#elif defined(__MINGW64__) || (defined(DEBUGGING) &amp;&amp; defined(NV=
_IS_DOUBLE))<br>typedef __float128 float128 __attribute__ ((aligned(8)));<b=
r>#else<br>typedef __float128 float128;<br>#endif<br></div><div><br></div><=
div>Compilers that are neither <a href=3D"http://mingw.org">mingw.org</a> o=
r mingw-w64 are rejected outright.</div><div>The &quot;#if&quot; block appl=
ies to the case where the compiler is a 32-bit <a href=3D"http://mingw.org"=
>mingw.org</a> compiler.</div><div>The &quot;#elif&quot; block applies to t=
he case where the compiler is either a 64-bit mingw-w64 compiler, or a 32-b=
it mingw compiler (either <a href=3D"http://mingw.org">mingw.org</a> or min=
gw-w64) on a debugging build of perl with an nvtype of double.</div><div>Th=
e&quot;#else&quot; block (where no alteration to byte alignment is needed) =
applies to=C2=A0 all other scenarios involving mingw compilers.</div><div><=
br></div><div>When I build my USE_QUADMATH perl-5.33.6 using a 64-bit mingw=
-w64 compiler (the &quot;#if&quot; case), the perl that is built crashes on=
 start up. I&#39;m feeling confident that this happens because the alignmen=
t has not been adjusted.</div><div>When I build my USE_QUADMATH perl-5.33.6=
 using a 32-bit mingw-w64 compiler (the &quot;#else&quot; case), the perl t=
hat is built runs without issue.=C2=A0

I&#39;m feeling confident that this happens because the alignment needs no =
adjustment.</div><div><br></div><div>I&#39;ve attached &#39;fail_32_q.txt&#=
39;, which lists the test failures for my 32-bit USE_QUADMATH build. (Only =
5 test files producing failures - pretty chuffed about that.)</div><div>And=
 I&#39;ve also attached &#39;V_32_q.txt&#39;, which provides the &quot;perl=
 -V&quot; output for this 32-bit USE_QUADMATH build.</div><div>Any construc=
tive comments/observations are *most* welcome.=C2=A0</div><div><br></div><d=
iv>My questions are:</div><div><br></div><div>1) With any working perl on W=
indows, how do I find out what the byte alignment is ?</div><div>$Config{al=
ignbytes} always reports &quot;8&quot;. But I suspect that&#39;s just becau=
se that&#39;s the value specified in win32/config.gc.</div><div>I did try a=
ltering that specified value in win32/config.gc, and $Config{alignbytes} al=
ways matched the value that I specified - but I could see no evidence that =
the byte alignment was in fact being altered by those changes.</div><div><b=
r></div><div>2) How/where, within the perl source, do I introduce those byt=
e-alignment alterations=C2=A0 to match the settings I&#39;ve applied in Mat=
h-Float128 ?</div><div><br></div><div>For the moment, I&#39;ll just concent=
rate on the 32-bit USE_QUADMATH build, as it&#39;s basically usable.</div><=
div>Solving the test failures there will, hopefully, transfer across to the=
 64-bit builds once I&#39;ve sorted out their alignmentl issues</div><div><=
br></div><div>Cheers,</div><div>Rob</div><div><br></div><div>PS=C2=A0</div>=
<div>Thanks for the heads up on the &#39;make minitest_prep&#39; and &#39;m=
ake minitest&#39; options, Jim.</div><div>There&#39;s a problem with=C2=A0E=
xtUtils-PL2Bat that&#39;s currently limiting their usefulness on windows fo=
r this particular exercise.</div><div>I hope to fix that eventually, of cou=
rse - but even so, it&#39;s handy to know of the availability of this stuff=
 on other systems. (I also spend time on Debian and Ubuntu, these days.)</d=
iv><div>As for the 20 years you alluded to .... well, they&#39;ve provided =
numerous challenges, plenty of frustrations and lots of egg-on-face moments=
, but the overall feeling continues to be one of delight=C2=A0and enjoyment=
.. (No altruism here - just plain self-indulgence ;-)</div><div><br></div><d=
iv>=C2=A0</div><div><br></div></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 2, 2021 at 2:19 AM &lt;<a h=
ref=3D"mailto:hv@crypt.org">hv@crypt.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">sisyphus &lt;<a href=3D"mailto:sisy=
phus359@gmail.com" target=3D"_blank">sisyphus359@gmail.com</a>&gt; wrote:<b=
r>
[...]<br>
:Any ideas on what I need to do next ?<br>
<br>
Can you run the same command under a debugger and set a breakpoint just<br>
before the vutil.c error, to take a look at the string it is parsing?<br>
That would seem like the first critical clue: whether is is (say) &quot;-5.=
008&quot;<br>
or something totally mangled.<br>
<br>
Hugo<br>
</blockquote></div>

--000000000000f6e4b905b7fef1bf--
--000000000000f6e4bc05b7fef1c1
Content-Type: text/plain; charset="US-ASCII"; name="fail_32_q.txt"
Content-Disposition: attachment; filename="fail_32_q.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_kjh5pyja0>
X-Attachment-Id: f_kjh5pyja0

VGVzdCBTdW1tYXJ5IFJlcG9ydA0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kb3AvaW5jLnQgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChXc3Rh
dDogMCBUZXN0czogODUgRmFpbGVkOiA0KQ0KICBGYWlsZWQgdGVzdHM6ICA0NCwgNDgsIDUyLCA1
Ng0Kb3AvdGFpbnQudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChXc3RhdDogMCBUZXN0czogMTA1NCBGYWlsZWQ6IDIpDQogIEZhaWxlZCB0
ZXN0czogIDEsIDQ2Mw0KcG9ydGluZy9wb2RfcnVsZXMudCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIChXc3RhdDogMCBUZXN0czogOCBGYWlsZWQ6IDEpDQog
IEZhaWxlZCB0ZXN0OiAgMw0KcG9ydGluZy9yZWdlbi50ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChXc3RhdDogNjUyODAgVGVzdHM6IDE0IEZhaWxl
ZDogMCkNCiAgTm9uLXplcm8gZXhpdCBzdGF0dXM6IDI1NQ0KICBQYXJzZSBlcnJvcnM6IEJhZCBw
bGFuLiAgWW91IHBsYW5uZWQgNDMgdGVzdHMgYnV0IHJhbiAxNC4NCi4uL2NwYW4vRXh0VXRpbHMt
UEwyQmF0L3QvbWFrZV9leGVjdXRhYmxlLnQgICAgICAgICAgICAgICAgICAgICAgICAoV3N0YXQ6
IDExNzc2IFRlc3RzOiAxMTIgRmFpbGVkOiA0NikNCiAgRmFpbGVkIHRlc3RzOiAgNS03LCAxMC0x
MSwgMTUtMTYsIDIwLTIxLCAyNS0yNiwgMzAtMzENCiAgICAgICAgICAgICAgICAzNS0zNiwgNDAt
NDIsIDQ1LTQ2LCA1MC01MSwgNTUtNTYsIDYwLTYxDQogICAgICAgICAgICAgICAgNjUtNjYsIDcw
LTcxLCA3NS03NiwgODAtODEsIDg1LTg2LCA5MC05MQ0KICAgICAgICAgICAgICAgIDk1LTk2LCAx
MDAtMTAxLCAxMDUtMTA2LCAxMTAtMTExDQogIE5vbi16ZXJvIGV4aXQgc3RhdHVzOiA0Ng0KLi4v
ZGlzdC9OZXQtUGluZy90LzQ1MF9zZXJ2aWNlLnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIChXc3RhdDogMCBUZXN0czogMjYgRmFpbGVkOiAwKQ0KICBUT0RPIHBhc3NlZDogICA5
DQouLi9leHQvSVBDLU9wZW4zL3QvSVBDLU9wZW4zLnQgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKFdzdGF0OiAwIFRlc3RzOiA0NSBGYWlsZWQ6IDApDQogIFRPRE8gcGFzc2Vk
OiAgIDI1DQpGaWxlcz0yNjcyLCBUZXN0cz0xMTI5OTcyLCAxODA4IHdhbGxjbG9jayBzZWNzICg2
Ni4yOCB1c3IgKyAgNS41MiBzeXMgPSA3MS44MSBDUFUpDQpSZXN1bHQ6IEZBSUwNCm1ha2U6ICoq
KiBbR05VbWFrZWZpbGU6MTk0NTogdGVzdF0gRXJyb3IgNTM=
--000000000000f6e4bc05b7fef1c1
Content-Type: text/plain; charset="US-ASCII"; name="V_32_q.txt"
Content-Disposition: attachment; filename="V_32_q.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_kjh5qath1>
X-Attachment-Id: f_kjh5qath1

U3VtbWFyeSBvZiBteSBwZXJsNSAocmV2aXNpb24gNSB2ZXJzaW9uIDMzIHN1YnZlcnNpb24gNikg
Y29uZmlndXJhdGlvbjoNCiAgIA0KICBQbGF0Zm9ybToNCiAgICBvc25hbWU9TVNXaW4zMg0KICAg
IG9zdmVycz02LjEuNzYwMQ0KICAgIGFyY2huYW1lPU1TV2luMzIteDg2LW11bHRpLXRocmVhZC02
NGludC1xdWFkbWF0aA0KICAgIHVuYW1lPScnDQogICAgY29uZmlnX2FyZ3M9J3VuZGVmJw0KICAg
IGhpbnQ9cmVjb21tZW5kZWQNCiAgICB1c2Vwb3NpeD10cnVlDQogICAgZF9zaWdhY3Rpb249dW5k
ZWYNCiAgICB1c2VpdGhyZWFkcz1kZWZpbmUNCiAgICB1c2VtdWx0aXBsaWNpdHk9ZGVmaW5lDQog
ICAgdXNlNjRiaXRpbnQ9ZGVmaW5lDQogICAgdXNlNjRiaXRhbGw9dW5kZWYNCiAgICB1c2Vsb25n
ZG91YmxlPXVuZGVmDQogICAgdXNlbXltYWxsb2M9bg0KICAgIGRlZmF1bHRfaW5jX2V4Y2x1ZGVz
X2RvdD1kZWZpbmUNCiAgQ29tcGlsZXI6DQogICAgY2M9J2djYycNCiAgICBjY2ZsYWdzID0nIC1E
V0lOMzIgLWZkaWFnbm9zdGljcy1jb2xvcj1uZXZlciAtRFBFUkxfVEVYVE1PREVfU0NSSVBUUyAt
RFBFUkxfSU1QTElDSVRfQ09OVEVYVCAtRFBFUkxfSU1QTElDSVRfU1lTIC1EVVNFX1BFUkxJTyAt
RF9fVVNFX01JTkdXX0FOU0lfU1RESU8gLWZ3cmFwdiAtZm5vLXN0cmljdC1hbGlhc2luZyAtbW1z
LWJpdGZpZWxkcycNCiAgICBvcHRpbWl6ZT0nLXMgLU8yJw0KICAgIGNwcGZsYWdzPSctRFdJTjMy
Jw0KICAgIGNjdmVyc2lvbj0nJw0KICAgIGdjY3ZlcnNpb249JzguMy4wJw0KICAgIGdjY29zYW5k
dmVycz0nJw0KICAgIGludHNpemU9NA0KICAgIGxvbmdzaXplPTQNCiAgICBwdHJzaXplPTQNCiAg
ICBkb3VibGVzaXplPTgNCiAgICBieXRlb3JkZXI9MTIzNDU2NzgNCiAgICBkb3VibGVraW5kPTMN
CiAgICBkX2xvbmdsb25nPWRlZmluZQ0KICAgIGxvbmdsb25nc2l6ZT04DQogICAgZF9sb25nZGJs
PWRlZmluZQ0KICAgIGxvbmdkYmxzaXplPTEyDQogICAgbG9uZ2RibGtpbmQ9Mw0KICAgIGl2dHlw
ZT0nbG9uZyBsb25nJw0KICAgIGl2c2l6ZT04DQogICAgbnZ0eXBlPSdfX2Zsb2F0MTI4Jw0KICAg
IG52c2l6ZT0xNg0KICAgIE9mZl90PSdsb25nIGxvbmcnDQogICAgbHNlZWtzaXplPTgNCiAgICBh
bGlnbmJ5dGVzPTMyDQogICAgcHJvdG90eXBlPWRlZmluZQ0KICBMaW5rZXIgYW5kIExpYnJhcmll
czoNCiAgICBsZD0nZysrJw0KICAgIGxkZmxhZ3MgPSctcyAtTCJDOlxwZXJsLTUuMzMuNi1xXGxp
YlxNU1dpbjMyLXg4Ni1tdWx0aS10aHJlYWQtNjRpbnQtcXVhZG1hdGhcQ09SRSIgLUwiQzpcXzMy
XGdjYy1zdHJhdy04MzBcbWluZ3czMlxsaWIiJw0KICAgIGxpYnB0aD1DOlxfMzJcZ2NjLXN0cmF3
LTgzMFxtaW5ndzMyXGxpYiBDOlxfMzJcZ2NjLXN0cmF3LTgzMFxtaW5ndzMyXGk2ODYtdzY0LW1p
bmd3MzJcbGliIEM6XF8zMlxtc3lzXzgzMFwxLjBcbG9jYWxcbGliIEM6XF8zMlxnY2Mtc3RyYXct
ODMwXG1pbmd3MzJcbGliXGdjY1xpNjg2LXc2NC1taW5ndzMyXDguMy4wDQogICAgbGlicz0gLWxt
b2xkbmFtZSAtbGtlcm5lbDMyIC1sdXNlcjMyIC1sZ2RpMzIgLWx3aW5zcG9vbCAtbGNvbWRsZzMy
IC1sYWR2YXBpMzIgLWxzaGVsbDMyIC1sb2xlMzIgLWxvbGVhdXQzMiAtbG5ldGFwaTMyIC1sdXVp
ZCAtbHdzMl8zMiAtbG1wciAtbHdpbm1tIC1sdmVyc2lvbiAtbG9kYmMzMiAtbG9kYmNjcDMyIC1s
Y29tY3RsMzIgLWxxdWFkbWF0aA0KICAgIHBlcmxsaWJzPSAtbG1vbGRuYW1lIC1sa2VybmVsMzIg
LWx1c2VyMzIgLWxnZGkzMiAtbHdpbnNwb29sIC1sY29tZGxnMzIgLWxhZHZhcGkzMiAtbHNoZWxs
MzIgLWxvbGUzMiAtbG9sZWF1dDMyIC1sbmV0YXBpMzIgLWx1dWlkIC1sd3MyXzMyIC1sbXByIC1s
d2lubW0gLWx2ZXJzaW9uIC1sb2RiYzMyIC1sb2RiY2NwMzIgLWxjb21jdGwzMiAtbHF1YWRtYXRo
DQogICAgbGliYz0NCiAgICBzbz1kbGwNCiAgICB1c2VzaHJwbGliPXRydWUNCiAgICBsaWJwZXJs
PWxpYnBlcmw1MzMuYQ0KICAgIGdudWxpYmNfdmVyc2lvbj0nJw0KICBEeW5hbWljIExpbmtpbmc6
DQogICAgZGxzcmM9ZGxfd2luMzIueHMNCiAgICBkbGV4dD1kbGwNCiAgICBkX2Rsc3ltdW49dW5k
ZWYNCiAgICBjY2RsZmxhZ3M9JyAnDQogICAgY2NjZGxmbGFncz0nICcNCiAgICBsZGRsZmxhZ3M9
Jy1tZGxsIC1zIC1MIkM6XHBlcmwtNS4zMy42LXFcbGliXE1TV2luMzIteDg2LW11bHRpLXRocmVh
ZC02NGludC1xdWFkbWF0aFxDT1JFIiAtTCJDOlxfMzJcZ2NjLXN0cmF3LTgzMFxtaW5ndzMyXGxp
YiInDQoNCg0KQ2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMgYmluYXJ5IChmcm9tIGxpYnBlcmwpOiAN
CiAgQ29tcGlsZS10aW1lIG9wdGlvbnM6DQogICAgSEFTX1RJTUVTDQogICAgSEFWRV9JTlRFUlBf
SU5URVJODQogICAgTVVMVElQTElDSVRZDQogICAgUEVSTElPX0xBWUVSUw0KICAgIFBFUkxfQ09Q
WV9PTl9XUklURQ0KICAgIFBFUkxfRE9OVF9DUkVBVEVfR1ZTVg0KICAgIFBFUkxfSU1QTElDSVRf
Q09OVEVYVA0KICAgIFBFUkxfSU1QTElDSVRfU1lTDQogICAgUEVSTF9NQUxMT0NfV1JBUA0KICAg
IFBFUkxfT1BfUEFSRU5UDQogICAgUEVSTF9QUkVTRVJWRV9JVlVWDQogICAgVVNFXzY0X0JJVF9J
TlQNCiAgICBVU0VfSVRIUkVBRFMNCiAgICBVU0VfTEFSR0VfRklMRVMNCiAgICBVU0VfTE9DQUxF
DQogICAgVVNFX0xPQ0FMRV9DT0xMQVRFDQogICAgVVNFX0xPQ0FMRV9DVFlQRQ0KICAgIFVTRV9M
T0NBTEVfTlVNRVJJQw0KICAgIFVTRV9MT0NBTEVfVElNRQ0KICAgIFVTRV9QRVJMSU8NCiAgICBV
U0VfUEVSTF9BVE9GDQogICAgVVNFX1FVQURNQVRIDQogIEJ1aWx0IHVuZGVyIE1TV2luMzINCiAg
Q29tcGlsZWQgYXQgSmFuICAzIDIwMjEgMjM6MDQ6MDINCiAgQElOQzoNCiAgICAuLlxsaWINCiAg
ICBDOi9jb21wL3BlcmwtNS4zMy42LXEvbGliDQo=
--000000000000f6e4bc05b7fef1c1--
0
sisyphus359
1/3/2021 1:27:59 PM
--000000000000b81bbf05b806f533
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 4, 2021 at 12:27 AM sisyphus <sisyphus359@gmail.com> wrote:

>
> When I build my USE_QUADMATH perl-5.33.6 using a 64-bit mingw-w64 compiler
> (the "#if" case), the perl that is built crashes on start up. I'm feeling
> confident that this happens because the alignment has not been adjusted.
>

Correction: =~s/"#if"/"#elif"/

Cheers,
Rob

--000000000000b81bbf05b806f533
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jan 4, 2021 at 12:27 AM sisyphus =
&lt;<a href=3D"mailto:sisyphus359@gmail.com">sisyphus359@gmail.com</a>&gt; =
wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>Whe=
n I build my USE_QUADMATH perl-5.33.6 using a 64-bit mingw-w64 compiler (th=
e &quot;#if&quot; case), the perl that is built crashes on start up. I&#39;=
m feeling confident that this happens because the alignment has not been ad=
justed.</div></div></div></blockquote><div><br></div><div>Correction: =3D~s=
/&quot;#if&quot;/&quot;#elif&quot;/=C2=A0</div><div><br></div><div>Cheers,<=
/div><div>Rob</div><div><br></div></div></div>

--000000000000b81bbf05b806f533--
0
sisyphus359
1/3/2021 11:01:41 PM
--000000000000b522bb05b813794a
Content-Type: multipart/alternative; boundary="000000000000b522b805b8137948"

--000000000000b522b805b8137948
Content-Type: text/plain; charset="UTF-8"

Hi,
I've got the 64-bit build working now (via a small patch to perl.h) -
pretty much the same test failures as the 32-bit build.
See fail_64_q_only.txt attached.
The op/taint.t and ../cpan/ExtUtils-PL2Bat/t/make_executable.t test
failures occur because libquadmath-0.dll is not being found.
It's in CCHOME/bin .... I don't yet know why it's not being found.

Also attached (diffs.txt) are the patches I've used to get to this stage.
They still require a little finessing.
They're against current blead up to and including commit b52b12ab.

I'm not really seeking any specific assistance at the moment - just
providing those attachments in case someone here wants to take a look.

Once I've "matured" things a bit, and run some thorough checks for
portability issues, I'll create an Issue over at
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues and see if
anyone over there is interested in doing some testing and improving.

Cheers,
Rob

--000000000000b522b805b8137948
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div></div><div>I&#39;ve got the 64-bit build working n=
ow (via a small patch to perl.h) - pretty much the same test failures as th=
e 32-bit build.</div><div>See fail_64_q_only.txt attached.</div><div>The=C2=
=A0op/taint.t and=C2=A0../cpan/ExtUtils-PL2Bat/t/make_executable.t test fai=
lures occur because libquadmath-0.dll is not being found.</div><div>It&#39;=
s in CCHOME/bin .... I don&#39;t yet know why it&#39;s not being found.</di=
v><div><br></div><div>Also attached (diffs.txt) are the patches I&#39;ve us=
ed to get to this stage. They still require a little finessing.</div><div>T=
hey&#39;re against current blead up to and including=C2=A0commit b52b12ab.<=
/div><div><br></div><div>I&#39;m not really seeking any specific assistance=
 at the moment - just providing those attachments in case someone here want=
s to take a look.<br></div><div><br></div><div>Once I&#39;ve &quot;matured&=
quot; things a bit, and run some thorough checks for portability issues, I&=
#39;ll create an Issue over at=C2=A0<a href=3D"https://github.com/Strawberr=
yPerl/Perl-Dist-Strawberry/issues">https://github.com/StrawberryPerl/Perl-D=
ist-Strawberry/issues</a> and see if anyone over there is interested in doi=
ng some testing and improving.</div><div><br></div><div>Cheers,</div><div>R=
ob</div><div><br></div></div>

--000000000000b522b805b8137948--
--000000000000b522bb05b813794a
Content-Type: text/plain; charset="US-ASCII"; name="fail_64_q_only.txt"
Content-Disposition: attachment; filename="fail_64_q_only.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_kjilyt560>
X-Attachment-Id: f_kjilyt560

DQpvcC9pbmMudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKFdzdGF0OiAwIFRlc3RzOiA2NyBGYWlsZWQ6IDEpDQogIEZhaWxlZCB0ZXN0
OiAgMzANCm9wL3RhaW50LnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoV3N0YXQ6IDAgVGVzdHM6IDEwNTQgRmFpbGVkOiAyKQ0KICBGYWls
ZWQgdGVzdHM6ICAxLCA0NjMNCnBvcnRpbmcvcG9kX3J1bGVzLnQgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoV3N0YXQ6IDAgVGVzdHM6IDggRmFpbGVkOiAx
KQ0KICBGYWlsZWQgdGVzdDogIDMNCnBvcnRpbmcvcmVnZW4udCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoV3N0YXQ6IDY1MjgwIFRlc3RzOiAxNCBG
YWlsZWQ6IDApDQogIE5vbi16ZXJvIGV4aXQgc3RhdHVzOiAyNTUNCiAgUGFyc2UgZXJyb3JzOiBC
YWQgcGxhbi4gIFlvdSBwbGFubmVkIDQzIHRlc3RzIGJ1dCByYW4gMTQuDQouLi9jcGFuL0V4dFV0
aWxzLVBMMkJhdC90L21ha2VfZXhlY3V0YWJsZS50ICAgICAgICAgICAgICAgICAgICAgICAgKFdz
dGF0OiAxMTc3NiBUZXN0czogMTEyIEZhaWxlZDogNDYpDQogIEZhaWxlZCB0ZXN0czogIDUtNywg
MTAtMTEsIDE1LTE2LCAyMC0yMSwgMjUtMjYsIDMwLTMxDQogICAgICAgICAgICAgICAgMzUtMzYs
IDQwLTQyLCA0NS00NiwgNTAtNTEsIDU1LTU2LCA2MC02MQ0KICAgICAgICAgICAgICAgIDY1LTY2
LCA3MC03MSwgNzUtNzYsIDgwLTgxLCA4NS04NiwgOTAtOTENCiAgICAgICAgICAgICAgICA5NS05
NiwgMTAwLTEwMSwgMTA1LTEwNiwgMTEwLTExMQ0KICBOb24temVybyBleGl0IHN0YXR1czogNDYN
Cg==
--000000000000b522bb05b813794a
Content-Type: text/plain; charset="US-ASCII"; name="diffs.txt"
Content-Disposition: attachment; filename="diffs.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_kjim44ri1>
X-Attachment-Id: f_kjim44ri1

LS0tIHBlcmwuaF9vcmlnCTIwMjEtMDEtMDQgMTQ6MjM6MzEgKzExMDANCisrKyBwZXJsLmgJMjAy
MS0wMS0wNCAyMzoxMDowMiArMTEwMA0KQEAgLTIxNzgsNyArMjE3OCwxMSBAQA0KICMgIGVuZGlm
DQogI2VuZGlmDQogDQorI2lmIGRlZmluZWQoVVNFX1FVQURNQVRIKSAmJiBkZWZpbmVkKF9fTUlO
R1c2NF9fKQ0KK3R5cGVkZWYgTlZUWVBFIE5WIF9fYXR0cmlidXRlX18gKChhbGlnbmVkKDgpKSk7
DQorI2Vsc2UNCiB0eXBlZGVmIE5WVFlQRSBOVjsNCisjZW5kaWYNCiANCiAjaWZkZWYgSV9JRUVF
RlANCiAjICAgaW5jbHVkZSA8aWVlZWZwLmg+DQotLS0gd2luMzIvR05VbWFrZWZpbGVfb3JpZwky
MDIxLTAxLTA0IDE0OjIzOjMzICsxMTAwDQorKysgd2luMzIvR05VbWFrZWZpbGUJMjAyMS0wMS0w
NCAyMjozODo0OSArMTEwMA0KQEAgLTEyOSw2ICsxMjksMTMgQEANCiAjVVNFX0xPTkdfRE9VQkxF
IDo9IGRlZmluZQ0KIA0KICMNCisjIFVuY29tbWVudCB0aGVzZSBpZiB5b3Ugd2FudCB0byBzdXBw
b3J0IHRoZSB1c2Ugb2YgX19mbG9hdDEyOCBpbiBHQ0MgYnVpbGRzLg0KKyMgVGhpcyBvcHRpb24g
aXMgbm90IHN1cHBvcnRlZCBmb3IgTVNWQyBidWlsZHMuDQorIw0KKyNVU0VfUVVBRE1BVEggOj0g
ZGVmaW5lDQorI0lfUVVBRE1BVEggOj0gZGVmaW5lDQorDQorIw0KICMgQ29tbWVudCB0aGlzIG91
dCBpZiB5b3Ugd2FudCB0byBidWlsZCBwZXJsIHdpdGhvdXQgX19VU0VfTUlOR1dfQU5TSV9TVERJ
TyBkZWZpbmVkLg0KICMgKElmIHlvdSdyZSBidWlsZGluZyBwZXJsIHdpdGggVVNFX0xPTkdfRE9V
QkxFIGRlZmluZWQgdGhlbg0KICMgX19VU0VfTUlOR1dfQU5TSV9TVERJTyB3aWxsIGJlIGRlZmlu
ZWQgd2hldGhlciBvciBub3QgdGhpcyBpcyB1bmNvbW1lbnRlZC4pDQpAQCAtNDc4LDYgKzQ4NSwx
MCBAQA0KIEFSQ0hOQU1FCTo9ICQoQVJDSE5BTUUpLWxkDQogZW5kaWYNCiANCitpZmVxICgkKFVT
RV9RVUFETUFUSCksZGVmaW5lKQ0KK0FSQ0hOQU1FCTo9ICQoQVJDSE5BTUUpLXF1YWRtYXRoDQor
ZW5kaWYNCisNCiAjIFNldCB0aGUgaW5zdGFsbCBsb2NhdGlvbiBvZiB0aGUgY29tcGlsZXIgaGVh
ZGVycy9saWJyYXJpZXMuDQogIyBUaGVzZSBhcmUgc2F2ZWQgaW50byAkQ29uZmlne2luY3BhdGh9
IGFuZCAkQ29uZmlne2xpYnB0aH0uDQogaWZuZXEgKCQoR0NDQ1JPU1MpLCkNCkBAIC01OTQsNiAr
NjA1LDEwIEBADQogCS1sY29tZGxnMzIgLWxhZHZhcGkzMiAtbHNoZWxsMzIgLWxvbGUzMiAtbG9s
ZWF1dDMyIC1sbmV0YXBpMzIgXA0KIAktbHV1aWQgLWx3czJfMzIgLWxtcHIgLWx3aW5tbSAtbHZl
cnNpb24gLWxvZGJjMzIgLWxvZGJjY3AzMiAtbGNvbWN0bDMyDQogDQoraWZlcSAoJChVU0VfUVVB
RE1BVEgpLGRlZmluZSkNCitMSUJGSUxFUwkrPSAtbHF1YWRtYXRoDQorZW5kaWYNCisNCiBpZmVx
ICgkKENGRyksRGVidWcpDQogT1BUSU1JWkUJPSAtZyAtTzINCiBMSU5LX0RCRwk9IC1nDQpAQCAt
MTIwOCw2ICsxMjIzLDcgQEANCiAJCSJ1c2VwZXJsaW89JChVU0VfUEVSTElPKSIJCVwNCiAJCSJ1
c2U2NGJpdGludD0kKFVTRV82NF9CSVRfSU5UKSIJCVwNCiAJCSJ1c2Vsb25nZG91YmxlPSQoVVNF
X0xPTkdfRE9VQkxFKSIJXA0KKwkJInVzZXF1YWRtYXRoPSQoVVNFX1FVQURNQVRIKSIJCVwNCiAJ
CSJ1c2VzaXRlY3VzdG9taXplPSQoVVNFX1NJVEVDVVNUKSIJXA0KIAkJImRlZmF1bHRfaW5jX2V4
Y2x1ZGVzX2RvdD0kKERFRkFVTFRfSU5DX0VYQ0xVREVTX0RPVCkiCVwNCiAJCSJMSU5LX0ZMQUdT
PSQoc3Vic3QgIixcIiwkKExJTktfRkxBR1MpKSJcDQpAQCAtMTQyNyw2ICsxNDQzLDkgQEANCiBp
ZmVxICgkKFVTRV9MT05HX0RPVUJMRSksZGVmaW5lKQ0KIAlAKGVjaG8gI2RlZmluZSBOVl9QUkVT
RVJWRVNfVVYmJiBcDQogCWVjaG8gI2RlZmluZSBOVl9QUkVTRVJWRVNfVVZfQklUUyA2NCk+PiBj
b25maWcuaA0KK2Vsc2UgaWZlcSAoJChVU0VfUVVBRE1BVEgpLGRlZmluZSkNCisJQChlY2hvICNk
ZWZpbmUgTlZfUFJFU0VSVkVTX1VWJiYgXA0KKwllY2hvICNkZWZpbmUgTlZfUFJFU0VSVkVTX1VW
X0JJVFMgNjQpPj4gY29uZmlnLmgNCiBlbHNlDQogCUAoZWNobyAjdW5kZWYgTlZfUFJFU0VSVkVT
X1VWJiYgXA0KIAllY2hvICNkZWZpbmUgTlZfUFJFU0VSVkVTX1VWX0JJVFMgNTMpPj4gY29uZmln
LmgNCkBAIC0xNDcwLDYgKzE0ODksMjEgQEANCiAJZWNobyAjZGVmaW5lIE5WZmYgIkxmIiYmIFwN
CiAJZWNobyAjZGVmaW5lIE5WZ2YgIkxnIiYmIFwNCiAJZWNobyAjZGVmaW5lIFVTRV9MT05HX0RP
VUJMRSk+PiBjb25maWcuaA0KK2Vsc2UgaWZlcSAoJChVU0VfUVVBRE1BVEgpLGRlZmluZSkNCisJ
QChlY2hvICNkZWZpbmUgR2NvbnZlcnReKHgsbix0LGJeKSBzcHJpbnRmXiheKGJeKSwiJSUuKiIi
TGciLF4obl4pLF4oeF4pXikmJiBcDQorCWVjaG8gI2RlZmluZSBIQVNfRlJFWFBRJiYgXA0KKwll
Y2hvICNkZWZpbmUgSEFTX0lTTkFOUSYmIFwNCisJZWNobyAjZGVmaW5lIEhBU19NT0RGUSYmIFwN
CisJZWNobyAjZGVmaW5lIEhBU19NT0RGUV9QUk9UTyYmIFwNCisJZWNobyAjZGVmaW5lIEhBU19T
UVJUUSYmIFwNCisJZWNobyAjZGVmaW5lIE5WVFlQRSBfX2Zsb2F0MTI4JiYgXA0KKwllY2hvICNk
ZWZpbmUgTlZTSVpFIDE2JiYgXA0KKwllY2hvICNkZWZpbmUgTlZfT1ZFUkZMT1dTX0lOVEVHRVJT
X0FUIDI1Ni4wKjI1Ni4wKjI1Ni4wKjI1Ni4wKjI1Ni4wKjI1Ni4wKjI1Ni4wKjIuMCoyLjAqMi4w
KjIuMCoyLjAqMi4wKjIuMCoyLjAmJiBcDQorCWVjaG8gI2RlZmluZSBOVmVmICJRZSImJiBcDQor
CWVjaG8gI2RlZmluZSBOVmZmICJRZiImJiBcDQorCWVjaG8gI2RlZmluZSBOVmdmICJRZyImJiBc
DQorCWVjaG8gI2RlZmluZSBJX1FVQURNQVRIJiYgXA0KKwllY2hvICNkZWZpbmUgVVNFX1FVQURN
QVRIKT4+IGNvbmZpZy5oDQogZWxzZQ0KIAlAKGVjaG8gI2RlZmluZSBHY29udmVydF4oeCxuLHQs
Yl4pIHNwcmludGZeKF4oYl4pLCIlJS4qZyIsXihuXiksXih4XileKSYmIFwNCiAJZWNobyAjdW5k
ZWYgSEFTX0ZSRVhQTCYmIFwNCkBAIC0xNDg4LDYgKzE1MjIsOCBAQA0KIAllY2hvICNkZWZpbmUg
TlZlZiAiZSImJiBcDQogCWVjaG8gI2RlZmluZSBOVmZmICJmIiYmIFwNCiAJZWNobyAjZGVmaW5l
IE5WZ2YgImciJiYgXA0KKwllY2hvICN1bmRlZiBJX1FVQURNQVRIJiYgXA0KKwllY2hvICN1bmRl
ZiBVU0VfUVVBRE1BVEgpIFwNCiAJZWNobyAjdW5kZWYgVVNFX0xPTkdfRE9VQkxFKT4+IGNvbmZp
Zy5oDQogZW5kaWYNCiBpZmVxICgkKFVTRV9DUExVU1BMVVMpLGRlZmluZSkNCi0tLSB3aW4zMi9j
b25maWdfSC5nY19vcmlnCTIwMjEtMDEtMDQgMTQ6MjM6MzMgKzExMDANCisrKyB3aW4zMi9jb25m
aWdfSC5nYwkyMDIxLTAxLTA0IDIyOjM5OjM0ICsxMTAwDQpAQCAtNjM4LDYgKzYzOCwxNCBAQA0K
ICAqLw0KIC8qI2RlZmluZSBJX05FVElORVRfSU4JLyAqKi8NCiANCisvKiBJX1FVQURNQVRIOg0K
KyAqCVRoaXMgc3ltYm9sLCBpZiBkZWZpbmVkLCBpbmRpY2F0ZXMgdGhhdCA8cXVhZG1hdGguaD4g
ZXhpc3RzIGFuZA0KKyAqCXNob3VsZCBiZSBpbmNsdWRlZC4NCisgKi8NCisjaWZuZGVmIElfUVVB
RE1BVEgNCisvKiNkZWZpbmUJSV9RVUFETUFUSAkJLyAqKi8NCisjZW5kaWYNCisNCiAvKiBJX1NZ
U19ESVI6DQogICoJVGhpcyBzeW1ib2wsIGlmIGRlZmluZWQsIGluZGljYXRlcyB0byB0aGUgQyBw
cm9ncmFtIHRoYXQgaXQgc2hvdWxkDQogICoJaW5jbHVkZSA8c3lzL2Rpci5oPi4NCkBAIC0zNzEw
LDEyICszNzE4LDYgQEANCiAgKi8NCiAvKiNkZWZpbmUJSV9QUk9UCQkvICoqLw0KIA0KLS8qIElf
UVVBRE1BVEg6DQotICoJVGhpcyBzeW1ib2wsIGlmIGRlZmluZWQsIGluZGljYXRlcyB0aGF0IDxx
dWFkbWF0aC5oPiBleGlzdHMgYW5kDQotICoJc2hvdWxkIGJlIGluY2x1ZGVkLg0KLSAqLw0KLS8q
I2RlZmluZQlJX1FVQURNQVRICQkvICoqLw0KLQ0KIC8qIElfU0hBRE9XOg0KICAqCVRoaXMgc3lt
Ym9sLCBpZiBkZWZpbmVkLCBpbmRpY2F0ZXMgdGhhdCA8c2hhZG93Lmg+IGV4aXN0cyBhbmQNCiAg
KglzaG91bGQgYmUgaW5jbHVkZWQuDQpAQCAtMzkzNSw2ICszOTM3LDEzIEBADQogICoJVGhlIGNv
bW1vbiB4ODYtc3R5bGUgODAtYml0IGxvbmcgZG91YmxlIGRvZXMgbm90IGhhdmUNCiAgKglhbiBp
bXBsaWNpdCBiaXQuDQogICovDQorLyogRkxUMTI4TUFOVEJJVFM6DQorICoJVGhpcyBzeW1ib2ws
IGlmIGRlZmluZWQsIHRlbGxzIGhvdyBtYW55IG1hbnRpc3NhIGJpdHMNCisgKgl0aGVyZSBhcmUg
aW4gX19mbG9hdDEyOCBwcmVjaXNpb24gZmxvYXRpbmcgcG9pbnQgZm9ybWF0Lg0KKyAqCU5vdGUg
dGhhdCB0aGlzIGlzIHVzdWFsbHkgRkxUMTI4X01BTlRfRElHIG1pbnVzIG9uZSwgc2luY2UNCisg
Kgl3aXRoIHRoZSBzdGFuZGFyZCBJRUVFIDc1NCBmb3JtYXRzIEZMVDEyOF9NQU5UX0RJRyBpbmNs
dWRlcw0KKyAqCXRoZSBpbXBsaWNpdCBiaXQsIHdoaWNoIGRvZXNuJ3QgcmVhbGx5IGV4aXN0Lg0K
KyAqLw0KIC8qIE5WTUFOVEJJVFM6DQogICoJVGhpcyBzeW1ib2wsIGlmIGRlZmluZWQsIHRlbGxz
IGhvdyBtYW55IG1hbnRpc3NhIGJpdHMNCiAgKgkobm90IGluY2x1ZGluZyBpbXBsaWNpdCBiaXQp
IHRoZXJlIGFyZSBpbiBhIFBlcmwgTlYuDQpAQCAtMzk0Miw2ICszOTUxLDcgQEANCiAgKi8NCiAj
ZGVmaW5lIERPVUJMRU1BTlRCSVRTICA1Mg0KICNkZWZpbmUgTE9OR0RCTE1BTlRCSVRTIDY0DQor
I2RlZmluZSBGTFQxMjhNQU5UQklUUwkxMTINCiAjZGVmaW5lIE5WTUFOVEJJVFMgICAgICA1Mg0K
IA0KIC8qIE5FRURfVkFfQ09QWToNCi0tLSB3aW4zMi9jb25maWdfc2guUExfb3JpZwkyMDIxLTAx
LTA0IDE0OjIzOjMzICsxMTAwDQorKysgd2luMzIvY29uZmlnX3NoLlBMCTIwMjEtMDEtMDMgMTc6
MTA6MjQgKzExMDANCkBAIC0xNDUsNyArMTQ1LDcgQEANCiANCiAjIHNldCA2NC1iaXQtaW50IG9w
dGlvbnMNCiBpZiAoJG9wdHt1c2U2NGJpdGludH0gZXEgJ2RlZmluZScpIHsNCi0gICAgaWYgKCRv
cHR7dXNlbG9uZ2RvdWJsZX0gZXEgJ2RlZmluZScpIHsNCisgICAgaWYgKCRvcHR7dXNlbG9uZ2Rv
dWJsZX0gZXEgJ2RlZmluZScgfHwgJG9wdHt1c2VxdWFkbWF0aH0gZXEgJ2RlZmluZScpIHsNCiAg
ICAgICAgICRvcHR7ZF9udl9wcmVzZXJ2ZXNfdXZ9ID0gJ2RlZmluZSc7DQogICAgICAgICAkb3B0
e252X3ByZXNlcnZlc191dl9iaXRzfSA9IDY0Ow0KICAgICB9DQpAQCAtMjI3LDYgKzIyNywyNCBA
QA0KICAgICAkb3B0e2xvbmdkYmxraW5kfSA9IDM7DQogICAgICRvcHR7bG9uZ2RibG1hbnRiaXRz
fSA9IDY0Ow0KIH0NCisjIHNldCBfX2Zsb2F0MTI4IG9wdGlvbnMNCitlbHNpZiAoJG9wdHt1c2Vx
dWFkbWF0aH0gZXEgJ2RlZmluZScpIHsNCisgICAgJG9wdHthbGlnbmJ5dGVzfSA9IDMyOw0KKyAg
ICAkb3B0e2RfR2NvbnZlcnR9ID0gJ3NwcmludGYoKGIpLCIlLioiIkxnIiwobiksKHgpKSc7DQor
ICAgICRvcHR7bnZzaXplfSA9IDE2Ow0KKyAgICAkb3B0e252dHlwZX0gPSAnX19mbG9hdDEyOCc7
DQorICAgICRvcHR7bnZfb3ZlcmZsb3dzX2ludGVnZXJzX2F0fSA9ICcyNTYuMCoyNTYuMCoyNTYu
MCoyNTYuMCoyNTYuMCoyNTYuMCoyNTYuMCoyLjAqMi4wKjIuMCoyLjAqMi4wKjIuMCoyLjAqMi4w
JzsNCisgICAgJG9wdHtudkVVZm9ybWF0fSA9ICciUUUiJzsNCisgICAgJG9wdHtudkZVZm9ybWF0
fSA9ICciUUYiJzsNCisgICAgJG9wdHtudkdVZm9ybWF0fSA9ICciUUciJzsNCisgICAgJG9wdHtu
dmVmb3JtYXR9ID0gJyJRZSInOw0KKyAgICAkb3B0e252ZmZvcm1hdH0gPSAnIlFmIic7DQorICAg
ICRvcHR7bnZnZm9ybWF0fSA9ICciUWciJzsNCisgICAgJG9wdHtudm1hbnRiaXRzfSA9IDExMjsN
CisgICAgJG9wdHtsb25nZGJsa2luZH0gPSAzOw0KKyAgICAkb3B0e2xvbmdkYmxtYW50Yml0c30g
PSA2NDsNCisgICAgJG9wdHtpX3F1YWRtYXRofSA9ICdkZWZpbmUnOw0KK30NCiBlbHNlIHsNCiAg
ICAgJG9wdHtkX0djb252ZXJ0fSA9ICdzcHJpbnRmKChiKSwiJS4qZyIsKG4pLCh4KSknOw0KICAg
ICAkb3B0e2RfUFJJRVVsZGJsfSA9ICd1bmRlZic7DQo=
--000000000000b522bb05b813794a--
0
sisyphus359
1/4/2021 1:57:34 PM
Reply: