New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support MIPS64 #150

Open
wbhart opened this Issue Jul 16, 2015 · 10 comments

Comments

Projects
None yet
2 participants
@wbhart
Owner

wbhart commented Jul 16, 2015

Andreas Enge has been helping us by reporting test failures on MIPS64, of which there are many. Most of the same things that are required for Windows64 also fix MIPS64.

MIPS64 has 32 bit pointers and either 32 or 64 bit longs, depending on ABI.

This issue will record failures as they are reported, and their fixes.

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Jul 16, 2015

Owner

The latest failure is the following

cbrt_newton_iteration....FAIL:
n = 4294967295, val = 1626, ans = 1625
../Makefile.subdirs:91: recipe for target '../build/ulong_extras/test/t-cbrt_newton_iteration_RUN' failed
make[1]: *** [../build/ulong_extras/test/t-cbrt_newton_iteration_RUN] Aborted
make[1]: Leaving directory '/home/privat/flint2/ulong_extras'

This is new code, added recently, which uses many hacks. Presumably a ulong/slong is missing somewhere, or something is being allocated as a ulong *, which is too small to contain the result.

Owner

wbhart commented Jul 16, 2015

The latest failure is the following

cbrt_newton_iteration....FAIL:
n = 4294967295, val = 1626, ans = 1625
../Makefile.subdirs:91: recipe for target '../build/ulong_extras/test/t-cbrt_newton_iteration_RUN' failed
make[1]: *** [../build/ulong_extras/test/t-cbrt_newton_iteration_RUN] Aborted
make[1]: Leaving directory '/home/privat/flint2/ulong_extras'

This is new code, added recently, which uses many hacks. Presumably a ulong/slong is missing somewhere, or something is being allocated as a ulong *, which is too small to contain the result.

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Jul 16, 2015

Owner

The test output indicates that ulong_extras/cbrt_newton_iteration is returning a faulty result.

The returned result is coincidentally cbrt(2^32) which is possibly a hint.

The code can return this value without further checking on a 32 bit machine, but not a 64 bit one. So at this stage I have no idea how this error can occur. The code looks absolutely fine to me.

Owner

wbhart commented Jul 16, 2015

The test output indicates that ulong_extras/cbrt_newton_iteration is returning a faulty result.

The returned result is coincidentally cbrt(2^32) which is possibly a hint.

The code can return this value without further checking on a 32 bit machine, but not a 64 bit one. So at this stage I have no idea how this error can occur. The code looks absolutely fine to me.

@kush789

This comment has been minimized.

Show comment
Hide comment
@kush789

kush789 Jul 16, 2015

Since the newton iteration method is the last test to be run among the cube root tests, I assume the other tests run successfully. All the others make use of n_cbrt_estimate(), which was the hacky part. Since the other tests pass, I guess there is no problem in that particular function too.

kush789 commented Jul 16, 2015

Since the newton iteration method is the last test to be run among the cube root tests, I assume the other tests run successfully. All the others make use of n_cbrt_estimate(), which was the hacky part. Since the other tests pass, I guess there is no problem in that particular function too.

@kush789

This comment has been minimized.

Show comment
Hide comment
@kush789

kush789 Jul 16, 2015

Ive figured this out, its actually a mistake in the constant "upper_limit" for a 32 bit system. It should be 1625, not 1626.

In line 74, we calculate upper_limit^3 (In this particular case), and log2(1626 ^ 3) is slightly larger than 32.

kush789 commented Jul 16, 2015

Ive figured this out, its actually a mistake in the constant "upper_limit" for a 32 bit system. It should be 1625, not 1626.

In line 74, we calculate upper_limit^3 (In this particular case), and log2(1626 ^ 3) is slightly larger than 32.

@kush789

This comment has been minimized.

Show comment
Hide comment
@kush789

kush789 Jul 16, 2015

The constant for a 64 bit system is right, log2 (2642245 ^ 3) is slightly less than 64

kush789 commented Jul 16, 2015

The constant for a 64 bit system is right, log2 (2642245 ^ 3) is slightly less than 64

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Jul 16, 2015

Owner

That's a bug either way. But now I have to work out why this is relevant on
MIPS64, which is a 64 bit machine.

Thanks for spotting this!

On 16 July 2015 at 15:30, Kushagra Singh notifications@github.com wrote:

Ive figured this out, its actually a mistake in the constant "upper_limit"
for a 32 bit system. It should be 1625, not 1626.

In line 74, we calculate upper_limit^3, and log2(1626 ^ 3) is slightly
larger than 32.


Reply to this email directly or view it on GitHub
#150 (comment).

Owner

wbhart commented Jul 16, 2015

That's a bug either way. But now I have to work out why this is relevant on
MIPS64, which is a 64 bit machine.

Thanks for spotting this!

On 16 July 2015 at 15:30, Kushagra Singh notifications@github.com wrote:

Ive figured this out, its actually a mistake in the constant "upper_limit"
for a 32 bit system. It should be 1625, not 1626.

In line 74, we calculate upper_limit^3, and log2(1626 ^ 3) is slightly
larger than 32.


Reply to this email directly or view it on GitHub
#150 (comment).

@kush789

This comment has been minimized.

Show comment
Hide comment
@kush789

kush789 Jul 16, 2015

The commit for that fix is here.
kush789@ade3423
Although I realize this is a different issue and not the reason behind test failures.

kush789 commented Jul 16, 2015

The commit for that fix is here.
kush789@ade3423
Although I realize this is a different issue and not the reason behind test failures.

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Jul 16, 2015

Owner

I believe I have already fixed it. Thanks.

Bill.

On 16 July 2015 at 16:20, Kushagra Singh notifications@github.com wrote:

The commit for that fix is here


Reply to this email directly or view it on GitHub
#150 (comment).

Owner

wbhart commented Jul 16, 2015

I believe I have already fixed it. Thanks.

Bill.

On 16 July 2015 at 16:20, Kushagra Singh notifications@github.com wrote:

The commit for that fix is here


Reply to this email directly or view it on GitHub
#150 (comment).

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Jul 21, 2015

Owner

Andreas reports that the problem with cbrt_newton_iteration is no longer the issue. There is a new failure:

n_rootrem....FAIL:
Passed Parameters : n = 129140164 root = 17
Answer generated : base = 4 remainder = 129140164
Expected answer : base = 3 remainder = 1

Owner

wbhart commented Jul 21, 2015

Andreas reports that the problem with cbrt_newton_iteration is no longer the issue. There is a new failure:

n_rootrem....FAIL:
Passed Parameters : n = 129140164 root = 17
Answer generated : base = 4 remainder = 129140164
Expected answer : base = 3 remainder = 1

@wbhart wbhart modified the milestone: flint-2.5 Jul 23, 2015

@wbhart wbhart removed this from the flint-2.5 milestone Aug 3, 2015

@wbhart

This comment has been minimized.

Show comment
Hide comment
@wbhart

wbhart Aug 4, 2015

Owner

The last reported bug has now been fixed. However, it only showed up on other 32 bit platforms. It shouldn't have shown up on a 64 bit platform.

Now we wait to hear if there are any more bugs on MIPS.

Owner

wbhart commented Aug 4, 2015

The last reported bug has now been fixed. However, it only showed up on other 32 bit platforms. It shouldn't have shown up on a 64 bit platform.

Now we wait to hear if there are any more bugs on MIPS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment