BigInt Division/Modulus Not Working

I've done some debugging myself. BigUintCore?.d -> divInt() should be modified from:

        uint b = 0;
        for (;y!=0; y>>=1) {
            ++b;
        }
        multibyteShr(result, x.data, b);

To:

        uint b = 0;
        y>>=1; // pre-shift once
        for (;y!=0; y>>=1) {
            ++b;
        }
        multibyteShr(result, x.data, b);

This only fixes division by powers of two. Division by anything else seems to make its way to BignumX86.d -> multibyteDivAssign(), which then throws an "object.Exception: Access Violation" error. For whatever reason dest.length is being corrupted when the function is called. If I force the system to use BignumNoAsm?.d this problem doesn't occur and both division and modulus seem to work alright (if the division by powers error is fixed.)

I couldn't say what's causing the array corruption error. I'm using v1.056 of the dmd compiler, which comes bundled with 0.99.9 Kai.

thanks, Sage Rat ... will apply this and set BigNumNoAsm? as the default until the corruption issue is resolved

hrm, BigInt.d now passes all unittests on WinXP/dmd-1.056 with version=TangoBignumNoAsm; enabled or disabled ... is that the case with Vista64 also?

Replying to kris:

hrm, BigInt.d now passes all unittests on WinXP/dmd-1.056 with version=TangoBignumNoAsm; enabled or disabled ... is that the case with Vista64 also?

Hm...I'm not sure. I tried running bob like so:

build\bin\win32\bob -vu -cdmd -rdmd -o="-unittest" .

This ran through just fine and popped out tango.lib. Then I tried adding my own unittest to the bottom of BigInt?.d (outside of the debug(UnitTest?) area), like so:

unittest {
	BigInt a = 12;
	BigInt b = 4;
	a = a/b;
	assert( a.toInt() == 147 );	
}

Nothing happened. It compiled through and popped out tango.lib again, indicating that my unittest wasn't actually being run at all. So then I revised it to this:

unittest {
	pragma(msg, "HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO!");
	
	BigInt a = 12;
	BigInt b = 4;
	a = a/b;
	assert( a.toInt() == 147 );
	assert( a.toInt() == 1 );
	assert( a.toInt() == 3 );
}

But as you see, it prints and just keeps on going merrily:

dmd -c -I./tango/core -I. -I./tango/core/vendor -unittest -oftango-math-BigInt?-u nittest.obj ./tango/math/BigInt.d HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HELLO! HEL LO! HELLO! HELLO! HELLO! HELLO! HELLO! dmd -c -I./tango/core -I. -I./tango/core/vendor -unittest -oftango-math-Bracket- unittest.obj ./tango/math/Bracket.d dmd -c -I./tango/core -I. -I./tango/core/vendor -unittest -oftango-math-Elliptic -unittest.obj ./tango/math/Elliptic.d dmd -c -I./tango/core -I. -I./tango/core/vendor -unittest -oftango-math-ErrorFun? ction-unittest.obj ./tango/math/ErrorFunction.d

Minus the -o="-unittest", my "HELLO!" disappears. But either way, everything runs through to completion.

We appear to be having a problem with our compiler, indeed.

bob won't actually help you run the unittests (at least not yet), so what you need to do is compile the library using

-o="-unittest -debug=UnitTest?"

and then link it with a minimal main.

Replying to larsivi:

bob won't actually help you run the unittests (at least not yet), so what you need to do is compile the library using -o="-unittest -debug=UnitTest?" and then link it with a minimal main.

Ahah, as you might detect, I've not yet used the unittest functionality. I thought it checked stuff during compilation.

Doing a clean, vanilla build from the repository, it loads and runs fine. My main() is like this:

import tango.io.Stdout;

int main() {
	Stdout("Hello").flush;

	return 0;
}

But then if I add my own unittest to the end of BigInt?.d:

struct BigInt {
	...

	unittest {
		BigInt a = 12;
		BigInt b = 4;
		a = a/b;
		assert( a.toInt() == 3 );
	}
}

Then I get an assert error. tango.core.Exception.AssertException@tango.math.BigInt(396): Assertion failure

any ideas on this one, Don?

Svn 5422 (23 March 2010) should have fixed both of these issues. Can someone check if it still fails?

As long as the unittests cover the issue, and do not fail, I see no reason to keep this ticket open.