Hi,

I have now gone back and checked this carefully.  The git repository at the commit before this one produces the right answer for 2 raisedTo: 64 on Aarch64.  It produces the wrong answer, 0, when this commit is included.

So it's this commit.  I'll look at the code to see if I can see why the code is bad.

BTW, how would one find the two referenced packages?

cheers

bruce

On 2021-06-20T22:44:36.000+02:00, Bruce O'Neel <bruce.oneel@pckswarms.ch> wrote:
Playing with Git bisect gets us to the commit below as the first bad one.

I started the git bisect with the two commits below.  The first one is bad, the second is the good one.

a783502b249c4a4fedc88b6e07837d405feab144 - zero9 - builds, zero error.


9f73148b8da4bc00278b83faa8da6b1c418fa54f - zero10 - builds works


Now this is not 100% guaranteed because one of the commits that git bisect chose had a build error so I had to mark that one as bad.  But the commit found does sound possible.

f632ee2888014ee88330ee994e13c9c609b57b5f is the first bad commit

commit f632ee2888014ee88330ee994e13c9c609b57b5f

Author: Eliot Miranda <eliot.miranda@gmail.com>

Date:   Wed Sep 2 10:45:27 2020 -0700


    CogVM source as per VMMaker.oscog-eem.2799/ClosedVMMaker-eem.98

    

    Ha!  I am *STUPID*.

    Integer overflow is not only determined by the upper 64-bits of a 64x64=>128 bit

    multiply being either all zero or all ones (0 or -1), but by the upper 64-bits

    being an extension of the most significant bit of the lower 64 bits!!


:040000 040000 ffb8fbcd8ab5e2ca1936429b2daaade62909c178 a5ac89d8b1d4980c5329835cdd3d4a2387b1fac5 M      nsspur64src

:040000 040000 e606dac14ee1db4ac59b0949bb03cd8e657d7aa7 be666051cd1d52d0055e319432b66a0fba61063e M      spur64src

:040000 040000 1dea4faf99821c60e2c2461076bfe8b99d4dea9b afbef904e8cbc7e4b80e1606420dd6293e12f3e9 M      spurlowcode64src

:040000 040000 f66c681004806d5880af7c0a3115038f4f2f3361 0e8d76bedcf22b6ad7497ea2e3dc44f3c36c2f3a M      spursista64src


On 2021-06-20T21:48:49.000+02:00, Craig Latta <craig@blackpagedigital.com> wrote:
Hi Ken--

      I brought up a development environment on a Raspberry Pi 4.

 > Unfortunately, my attempt to build a VM simulator on aarch64 fails due
 > to a divide by zero bug.
 >
 > Perhaps because
 >    16r8000000000000000 printStringHex. ==> '0'

      update-eem-463.mcm has a postload action which turns on Sista, 
which recompiles the system, which tries to recompile 
FloatArrayTest>>testFloatArrayPluginPrimitiveAtPut, which exercises this 
very bug during scanning, when trying to create the float 1e-127.

      For now I've rewritten testFloatArrayPluginPrimitiveAtPut and 
testFloatArrayPluginPrimitiveAt on my system to do nothing. When 
building GdbARMv8Plugin, there's some other kind of 
header-include-ordering mayhem, similar to the problem with Linux 
features.h when building the VM. (At least two levels of it, between 
bfd.h and the aarch64 simulator's config.h, and config.h and other 
system headers.) I expect no one has successfully built GdbARMv8Plugin 
on anything but a M1 macOS machine so far.


-C

--
Craig Latta  ::  research computer scientist
Black Page Digital  ::  Berkeley, California
663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE