It looks to me like a short is 16 bits and a long is 32 bits on SPARC32. But even finding documentation online which gives this information is difficult.
Bill. On 6 Dec, 23:02, Bill Hart <[EMAIL PROTECTED]> wrote: > You hopefully mean uint64_t, not u_int64_t. There should be no > occurrences of u_int64_t left in FLINT. If that's not the case, please > let me know. > > Also, if uint32_t is not available in 32 bit mode, your compiler is > either not c99 compliant or the machine does not have both a native 32 > bit type and a native 16 bit type, in which case FLINT will not work > on this machine. This is why the test fails. > > You definitely should not be defining uint64_t if you are in 32 bit > mode. But you do need to define uint16_t. The fact that it compiles at > all suggests something is very, very wrong. If the compiler is c99 > compliant, you should not need to define anything to make it compile. > If you do, FLINT can't support the machine at present. > > To debug this you need to know the values of: > > 1) FLINT_BITS (it's a macro in flint.h) > > 2) sizeof(uint32_t) > > 3) sizeof(uint16_t) > > If the machine truly is running in 32 bit mode the values you get > should be 32, 4 and 2. Only then will the FLINT tests pass. > > If you get 64 for number (1) then uint64_t and uint32_t should be > defined. In that case you should look at the values of > > 1) FLINT_BITS > > 2) sizeof(uint64_t) > > 3) sizeof(uint32_t) > > The values you should get in this case should be 64, 8, 4. Only then > will the FLINT tests pass. > > As for the quadratic sieve, yes it is included in FLINT 1.0, but is a > completely new beast (and much faster). Simply make QS to build it. > The program is called mpQS. It is fairly similar to the old > QuadraticSieve program, and with any luck the output is formatted the > same. > > The program now *requires* that the input is not prime, is not a > perfect power and has no small factors, i.e. you should remove all > factors up to 1000 and run the elliptic curve method for a few rounds > before calling the sieve. If you don't do this, mpQS will fail > silently. Paul Zimmerman opened a ticket at SD6 explaining precisely > how long to run GMP-ECM before running the quadratic sieve. I leave it > up to you whether to sort this out now or keep the old sieve for now. > There have been and will be no further changes to the old sieve so > nothing needs changing if you want to stick with the old sieve until > someone can sort out the trial factoring and ECM. > > Bill. > > On Dec 6, 10:11 pm, mabshoff <[EMAIL PROTECTED] > > dortmund.de> wrote: > > Okay, two things: > > > 1) I would love to get some feedback from Linux/Itanium with this > > since we have an open ticket for that. > > > 2) The test suite failed on Solaris 9/Sparc in 32 bit mode. I ran it > > three times and it was always the same failure: > > > <SNIP> > > Testing _fmpz_poly_max_bits1()... FAIL! > > <SNIP> > > At least one test FAILED! > > > real 36m41.403s > > user 37m30.350s > > sys 0m4.380s > > > I order to compile I had to define the following: > > > typedef unsigned int uint32_t; > > typedef unsigned long long u_int64_t; > > > I am fairly confident that those settings are correct for Solaris in > > 32 bit mode. > > > Bill: any suggestion how to debug this? > > > Cheers, > > > Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
