Looking at the Valgrind error report it does seem to be the SSE trick that is
causing Valgrind to think there is an error. This trick is used by
copyi,copyd,popcount,hamdist on the core2 machines and perhaps a few others ,
it's a perfectly valid trick and actually reads/writes no more data than
I see, thank you for your help and for saving a lot of my time!
If my target nehalem, then would it be Ok to configure MPIR as :
--host=nehalem-unknown-linux
?
yep , although I always use --build=
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" g
d
library.
And it works if I do not use --enable-fat. But linking with fat library
gives me error above.
On Mon, Jul 9, 2012 at 4:42 PM, Jason Moxham wrote:
> Ah , it looks like your linking against libgmp.a not libgmp.so ?
>
> --
> You received this message because you are subs
Ah , it looks like your linking against libgmp.a not libgmp.so ?
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr..
Hi
Try building it with just
./configure --enable-fat --enable-gmpcompat --prefix=/libs/mp-09.07.2012
I assume you are building it on a x86_64 linux system so the --host=... is not
necessary
Setting CC to gcc is not necessary , and I assume -fPIC is automatic
Any varibles set this way will di
The other way of doing this is to add
; PROLOGUE(symbol)
lines to my files - the semicolon means that YASM ignores these lines but I
think that configure will see them.
If this doesn't work, I can add macros for PROLOGUE(x) and GLOBAL_FUNC(x)
that evaluate to NUL in YASM but
On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
>
>
> > Hi
> >
> > I figured out what going on here , basically configure is failing to
> > populate config.h with the required
> > #define HAVE_NATIVE_mpn_addmul_2 1
> > and all the other
On Sun, 10 Jun 2012 08:07:39 -0700 (PDT)
jason wrote:
> Hi
>
> I figured out what going on here , basically configure is failing to
> populate config.h with the required
> #define HAVE_NATIVE_mpn_addmul_2 1
> and all the others , it has always done this on mingw64 but because of
> the way the C
Hi
Sorry for the delay.
I seem to remember that 64bit builds are limited to 2^37 bits (16GB) , I read
it somewhere on the GMP website ,I have no idea which part of MPIR has this
restriction.
Jason
---
MPIR-2.5.1 bug
#include
#include
Whoops , found this old email on my other computer :(
If there are any other emails that I should of have answered please repost them.
Thanks
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@
Sat, 9 Jun 2012 20:00:37 +0100
Jason Moxham wrote:
> I had a quick read of the license and it's nothing special , so
> mingw64 users probably wont have an objection , but I can imagine
> other (linux users for example)people who will object to downloading
> a package which co
I had a quick read of the license and it's nothing special , so mingw64 users
probably wont have an objection , but I can imagine other (linux users for
example)people who will object to downloading a package which contains some
parts which have a "commercial" license even though they won't be u
On Sat, 9 Jun 2012 18:30:31 +0100
Jason Moxham wrote:
> Hm , I just assumed yasm supported masm but it's nasm . What we
> need is a masm compatible free/open source program that I can get to
> work under mingw64 then. Getting it to work under mingw64 should be
> easy.We ca
As for the maintenance burden for mingw64 , it's been zero , the current
mingw64 compilers are broken , and the redc_2 include gmp.h rather than mpir.h
wouldn't be picked up in linux builds as all distributions of linux have gmp.h
in the path , I would of picked it up on mingw64 if at the time I
Hm , I just assumed yasm supported masm but it's nasm . What we need is a
masm compatible free/open source program that I can get to work under mingw64
then. Getting it to work under mingw64 should be easy.We can get rid of yasm
and use gas under linux and masm under msvc and this new ?asm?
What I'm saying that if msvc wants to go the masm route then I'm sure I can get
mingw64 to work with those source files , we would of course need the path in
mingw64 to specify where masm was , or perhaps if we keep the masm macros
simple (like we do anyway) then even the current mingw64 yasm wi
Hi
On Linux/cygwin/mingw32 we currently use both yasm and gas to build assembler
files , yasm to build intel format and gas to build AT&T format , I also got
some patches so we can use either always yasm or always gas without any changes
to the source files , so we could get rid of yasm or not
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-
On Sat, 9 Jun 2012 09:14:51 +0100
Jason Moxham wrote:
> This is based on the 2.5.1 branch
Thanks Jason, I have just downloaded it and saw that it is a minor
evolution of 2.5.1.
I assume that when 2.5.1 was branched from trunk, it worked on MSVC.
So what matters are any post release patc
This is based on the 2.5.1 branch
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-
Hi
I believe it's all 64bit cpu's , but I have a proper test now (from the gcc bug
tracker so we can just use that , rather than just exclude gcc-4.3.2 as some
gcc-4.3.2 have been patched
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
T
Yeah , it was a buggy compiler , I'll send details to the mingw64 team
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-dev
On Fri, 1 Jun 2012 07:52:54 +0100
Jason Moxham wrote:
> Hi
>
> it was on a sandybridge but there is nothing specific about so it
> should run on a core2
I have just built and tested the x64 static library build for
sandybridge from the MPIR SVN trunk and all tests passed.
Br
Hi
it was on a sandybridge but there is nothing specific about so it should run on
a core2
I'll try some other arches
Jason
On Fri, 1 Jun 2012 07:12:33 +0100
Jason Moxham wrote:
> Hi
>
> we get errors in these te
Hi
we get errors in these tests on mingw64
mpz/t-set_si
mpz/t-mul_i
mpz/t-fits
mpz/t-cmp_si
I'm sure they passed before , and we have made no changes , Brian I assume they
pass in MSVC ?
perhaps a compiler bug
Jason
--
You received this message because you are subscribed to the Google Group
There is another way to do this , make gcc accept the -m32 -m64 options , as
gcc is normally a "script" when the script has an -m32 option it calls our
current gcc and when our script has a -m64 option it calls
x86_64-w64-mingw32-gcc , same for all the other necessary build tools. This way
./co
Hi
I properly installed MinGW64 and built MPIR-2.5.0 and MPIR-2.5.1 , there were
two trivial corrections that were needed but otherwise all was fine but I've
only tried a few combinations so far.MinGW64 and 32 both support fat builds ,
although the 64bit fat build may break WIN64 exception?/epi
Yep , it looks like I have installed msys+mingw64 wrong , and even my previous
installation was wrong which would explain some dll test errors , I'll install
properly tomorrow and make sure I can compile mpir-2.5.0 and then look at 2.5.1
Jason
--
You received this message because you are subsc
The real problem is that it is a cross compiler , there is no way that
configure can determine any options correctly , you can get a basic C build
automatically (that why the tuning probably fails) , but other wise you have to
specify everything to configure.
The easiest way is to set it up as a
Hi
Tuning under windows/mingw*/cygwin has always been a bit flaky , and anyhow the
parameters for linux and windows should be practically identical.
On a different note , when we released mpir-2.5.1 , I didn't have a working
windows box so mingw* wasn't checked , however as the changes from 2.5
It looks like its related to this thread
http://groups.google.com/group/mpir-devel/browse_thread/thread/b440111d4048c1ec/70dfdfeee241edb2?lnk=gst&q=get_ux#70dfdfeee241edb2
a compiler bug but note the gcc version is 4.1.3 on netbsd on the gccfarm gcc70
jason
--
You received this message because
This configure line will be a much better generic x86_64 build , due to the way
the directory's are laid out
./configure --build=$(if [ $(./configfsf.guess | cut -f 1 -d -) = x86_64 ] ;
then echo k8-$(./config.guess | cut -f 2- -d -) ; else echo $(./config.guess) ;
fi)
make
make check
make ins
On 22 May 2012 10:10, Jeroen Demeyer wrote:
> Within the Sage project, we discovered several issues with the
> CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0. The code mostly
> works well, but there are a few things I would like to change.
>
> I would also like to add a configuration option
I think I can get it to fall back to -O1 which safe when it fails the test ,
but I don't know how to get it to add a flag if it fails a test , only how to
remove a flag if it fails a test, or we can just print a error message in
configure to say to use -fno-strict-aliasing
I think a fallback to
I imagine the performance hit is minimal . We have a simple testcase
int __attribute__((noinline))
foo(int i)
{
int *p = __builtin_malloc (4 * sizeof(int));
*p = 0;
p[i] = 1;
return *p;
}
extern void abort (void);
int main()
{
if (foo(0) != 1)
abort ();
return 0;
}
So we can reje
So what's the motivation for refusing to build MPIR with gcc-4.3.2?
The configure script essentially just says "it's broken" without
specifying how or why. I have built MPIR with gcc-4.3.2 on a GNU/Linux
x86_64 system with -march=nocona and built gcc with that MPIR and I had
no problems at al
I couldn't compile MPIR 2.5.1 on my windows 7 system with MSYS.
It stopped with a error in redc_2.c (in mpn/generic) gmp.h not a file
or directory.
When I changed #include"gmp.h" with #include"mpir.h" it compiled with
no errors.
I have little experiences with C or C++, I prefer Freebasic, so
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
Hi, Mark here...
Laptop HP G62: CPU - I3-370m, Memory - 8gb.
Tune: DIVREM_HENSEL_QR_1_THRESHOLD Fatal error: too many (11) failed
measurements (0.0)
-
Hi , Laptops running windows tend to not run the tuning suite very well due to
fluct
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
On Thursday 08 July 2010 16:00:46 Fredrik Johansson wrote:
> On Thu, Jul 8, 2010 at 4:51 PM, Jason Moxham
wrote:
> > The mulhi and mullo are exact unlike the mulmid , we could do an
> > approximate
> > mulhi which would be marginally faster.
> >
> > Jason
&g
On Thursday 08 July 2010 08:26:02 Fredrik Johansson wrote:
> On Wed, Jul 7, 2010 at 11:36 PM, Jason Moxham
wrote:
> > On Tuesday 06 July 2010 10:49:35 Bill Hart wrote:
> > > Frederick is working on mpz_mulhi, however one thing we *really* need
> > > (since t
On Tuesday 06 July 2010 10:49:35 Bill Hart wrote:
> Frederick is working on mpz_mulhi, however one thing we *really* need
> (since the interesting case for his applications is for a small number
> of limbs) is an x86_64 assembly version for the basecase, as at
> present I think we just use a full m
On Friday 02 July 2010 19:14:15 Cactus wrote:
> On Jul 2, 7:04 pm, Jason Moxham wrote:
> > On Friday 02 July 2010 18:46:33 Cactus wrote:
> > > On Jul 2, 5:00 pm, Jason Moxham wrote:
> > > > On Friday 02 July 2010 14:52:14 Jason Moxham wrote:
> > > > >
On Friday 02 July 2010 18:46:33 Cactus wrote:
> On Jul 2, 5:00 pm, Jason Moxham wrote:
> > On Friday 02 July 2010 14:52:14 Jason Moxham wrote:
> > > On Monday 28 June 2010 13:14:48 Jason Moxham wrote:
> > > > Hi
> > > >
> > > > Now we have r
On Friday 02 July 2010 14:52:14 Jason Moxham wrote:
> On Monday 28 June 2010 13:14:48 Jason Moxham wrote:
> > Hi
> >
> > Now we have removed the old cpu's here are some operating systems I
> > propose we remove explicit support for
> >
> > IRIX for mips
On Monday 28 June 2010 13:14:48 Jason Moxham wrote:
> Hi
>
> Now we have removed the old cpu's here are some operating systems I propose
> we remove explicit support for
>
> IRIX for mips
> OSF/TRU64 for alpha
> SunOS <=version 4 (version 5 is called solaris ie on
On Wednesday 30 June 2010 11:52:33 Cactus wrote:
> On Jun 30, 10:32 am, Jason Moxham wrote:
> > On Tuesday 29 June 2010 22:25:44 Cactus wrote:
> > > On Jun 29, 8:38 pm, Jason Moxham wrote:
> > > > On Friday 25 June 2010 20:16:15 Jason Moxham wrote:
> > >
On Tuesday 29 June 2010 22:25:44 Cactus wrote:
> On Jun 29, 8:38 pm, Jason Moxham wrote:
> > On Friday 25 June 2010 20:16:15 Jason Moxham wrote:
> > > Hi
> > >
> > > These cpu's also have no support from gcc , so again I think we should
> > > c
On Friday 25 June 2010 20:16:15 Jason Moxham wrote:
> Hi
>
> These cpu's also have no support from gcc , so again I think we should
> certainly remove them
>
> gmicro
> i860
> ibm032 or 032 or ROMP
> uxp or xp fujitsu 32bit vector supercomputer
>
I have removed
On Monday 28 June 2010 11:58:08 Jason Moxham wrote:
> On Friday 25 June 2010 20:16:15 Jason Moxham wrote:
> > Hi
> >
> > These cpu's also have no support from gcc , so again I think we should
> > certainly remove them
> >
> > gmicro
> > i860
>
Hi
Now we have removed the old cpu's here are some operating systems I propose we
remove explicit support for
IRIX for mips
OSF/TRU64 for alpha
SunOS <=version 4 (version 5 is called solaris ie on fulvia/mark.skynet)
DJGPP dos
OS2
Unicos cray's unix
pw32 posix on win32
Comments?
Jason
--
On Friday 25 June 2010 20:16:15 Jason Moxham wrote:
> Hi
>
> These cpu's also have no support from gcc , so again I think we should
> certainly remove them
>
> gmicro
> i860
> ibm032 or 032 or ROMP
> uxp or xp fujitsu 32bit vector supercomputer
>
> Note thes
ve to go somewhere or be removed.
Jason
On Friday 25 June 2010 18:33:31 Jason Moxham wrote:
> Hi
>
> I've have updated yasm to the latest svn , unfortunately it was not as easy
> as I thought , I was going to take a diff of the yasm svn's and just apply
> that to our yasm
trate on small items ie bug fixing/cleaning-up , stuff I can do
> in a few hours or in fits and starts , nothing where I have to sit
> down for a day or two :(
>
> On Jun 2, 10:18 pm, Jason Moxham wrote:
> > Hi , here are some thoughts about what we should/could do for the next
&
#x27;ll add them.
>
could you add 2.3 as well , for thing we know we wont do for a while
thanks
jason
> Bill.
>
> On 25 June 2010 09:02, Jason Moxham wrote:
> > Hi
> >
> > The only bit left to do is update trac , but I don't have the necessary
> > permissi
On Friday 25 June 2010 09:07:19 chrmhoffmann wrote:
> > MPIR 2.1.1 was released on 25th June 2010.
> >
> > * source tarball:http://www.mpir.org/mpir-2.1.1.tar.gz
> > * documentation:http://www.mpir.org/mpir-2.1.1.pdf
> > * full changelog:http://www.mpir.org/changes.html
> >
> > See the MPIR website
Hi
The only bit left to do is update trac , but I don't have the necessary
permissions to edit "milestones" , I can edit tickets OK .
Bill are you the one to ask?
Thanks
Jason
On Friday 25 June 2010 08:29:04 Jason Moxham wrote:
> Hi
>
> MPIR 2.1.1 was released on 25th
Hi
MPIR 2.1.1 was released on 25th June 2010.
* source tarball: http://www.mpir.org/mpir-2.1.1.tar.gz
* documentation: http://www.mpir.org/mpir-2.1.1.pdf
* full changelog: http://www.mpir.org/changes.html
See the MPIR website (www.mpir.org) for known issues and a list of
supported platfo
On Thursday 24 June 2010 10:35:39 Cactus wrote:
> On Jun 24, 4:53 am, Jason Moxham wrote:
> > On Friday 18 June 2010 08:18:03 Cactus wrote:
> > > On Jun 18, 7:33 am, degski wrote:
> > >
> > > Hi Degski,
> > >
> > > > As I ran
On Friday 18 June 2010 08:18:03 Cactus wrote:
> On Jun 18, 7:33 am, degski wrote:
>
> Hi Degski,
>
> > As I ran into trouble with the static c++ lib, I concluded that I
> > needed a dynamic lib, hence my problem was created.
>
> The fact that the DLL libraries include the C++ functions is
> mentio
On Thursday 10 June 2010 18:54:14 Fredrik Johansson wrote:
> Hi,
>
> What is the best way to scan an mpz for 1s or 0s in the direction towards
> less significant bits (mpz_scan0, mpz_scan1 scan towards more significant
> bits)?
>
Unfortunately , there is no easy way without delving into the intern
On Tuesday 08 June 2010 05:19:19 William Stein wrote:
> Hi,
>
> In case it comes up ever, I just built MPIR 1.2.2.p1 from source
> directly on the iPad
> (which is 100% equivalent to building on the iPhone).
>
> The only change was that I had to hack config.sub and
> yasm/config/config.sub. I just
On Tuesday 08 June 2010 06:39:38 Minh Nguyen wrote:
> Hi Bill,
>
> On Tue, Jun 8, 2010 at 4:29 AM, Bill Hart
wrote:
> > The files Changelog, NEWS
>
> These have been updated.
>
> > and AUTHORS are in the top level directory.
>
> I don't there are any new contributors in MPIR 2.1.0, so I'm leaving
Actually lots of files still say v2.1 or later , which is as it should be ,
only file with v3 code need to say v3 upwards , overall MPIR is now v3 though.
I will still do my code under the v2.1 or upwards (or both , if they are
incompatible)
Jason
On Tuesday 08 June 2010 04:55:55 Jason Moxham
On Monday 07 June 2010 21:47:37 Minh Nguyen wrote:
> Hi Bill,
>
> On Tue, Jun 8, 2010 at 4:29 AM, Bill Hart
wrote:
> > The files Changelog, NEWS
>
> Why does the file Changelog say this:
>
>
> The MPIR Library is free software; you can redistribute it and/or modify
> it under the terms of the GN
On Monday 07 June 2010 18:54:26 Jason Moxham wrote:
> On Monday 07 June 2010 14:38:32 Bill Hart wrote:
> > Is there anything left to do to make an MPIR release?
>
> No
>
> > Are there any reported bugs that still need to be fixed?
>
> None that will get fixed :) , t
On Monday 07 June 2010 14:38:32 Bill Hart wrote:
> Is there anything left to do to make an MPIR release?
>
No
> Are there any reported bugs that still need to be fixed?
>
None that will get fixed :) , the only serious bug is that we dont build on
fulvia.skynet ( we have been broken with cc for
On Thursday 03 June 2010 17:43:13 Bill Hart wrote:
> On 3 June 2010 15:00, Jason Moxham wrote:
> > On Thursday 03 June 2010 04:58:30 Jason Moxham wrote:
> >> On Wednesday 02 June 2010 17:45:26 Jason Moxham wrote:
> >> > Looks good , there are only 2 or 3 real erro
On Wednesday 02 June 2010 19:13:38 Bill Hart wrote:
> On 2 June 2010 19:10, Jason Moxham wrote:
> > On Wednesday 02 June 2010 18:23:31 Bill Hart wrote:
> >> Two comments:
> >>
> >> * Fat builds don't need to work on many systems. We only support x86
>
On Thursday 03 June 2010 04:58:30 Jason Moxham wrote:
> On Wednesday 02 June 2010 17:45:26 Jason Moxham wrote:
> > Looks good , there are only 2 or 3 real errors
> >
> > your cleo and iras errors are because you need to get icc in your path ,
> > you will hit 1 real err
On Wednesday 02 June 2010 17:45:26 Jason Moxham wrote:
> Looks good , there are only 2 or 3 real errors
>
> your cleo and iras errors are because you need to get icc in your path ,
> you will hit 1 real error then , but we can easily fix that.
>
I fixed it by just deleting the a
Hi , here are some thoughts about what we should/could do for the next
release.
1) Upgrade yasm to the latest (easy)
2) Upgrade gnu config to the latest ( dont know how difficult that is , but it
could fix some niggles we have , and it might simplify our specialisations.
3) Upgrade to the lat
because CFLAGS is already set it
will never test it , a slight design flaw.
Basically if you set CFLAGS or some other ENV then you have to set the lot.
Jason
On Wednesday 02 June 2010 20:57:40 Jason Moxham wrote:
> On Wednesday 02 June 2010 20:32:00 Pierrick Charron wrote:
> > Hi and t
On Wednesday 02 June 2010 20:32:00 Pierrick Charron wrote:
> Hi and thanks for your help.
>
> Yes i'm running on a 32-bit ubuntu on a 64-bit chip.
> I finally compiled MPIR just by doing an export ABI=32
>
> If you want me to help you to do some tests or need more informations
> feel free to ask !
any build you want , it doesn't matter if it makes
sense , you just wont get very far !
then make , make check
if that doesn't build , then try it without the ABI switch , and/or with
penryn replaced with i486,core2
Thanks
Jason
> 2010/6/2 Jason Moxham :
> > On Wednesday 02
On Wednesday 02 June 2010 19:55:57 Pierrick CHARRON wrote:
> Hi,
>
> I tried to compile MPIR on my laptop but got those errors :
>
> tmp-rshift.s: Assembler messages:
> tmp-rshift.s:53: Error: bad register name `%rbx'
> tmp-rshift.s:54: Error: bad register name `%rbx'
> .
>
> The full make log
ithout a
small test case
> Bill.
>
> On 2 June 2010 17:45, Jason Moxham wrote:
> > Looks good , there are only 2 or 3 real errors
> >
> > your cleo and iras errors are because you need to get icc in your path ,
> > you will hit 1 real error then , but we can
--enable-gmpcompat --
enable-assert --enable-alloca=debug
PASSED CC=gcc-3.3 CXX=g++-3.3 configure= --enable-cxx --enable-gmpcompat --
enable-assert --enable-alloca=debug --build=none-apple-darwin8.11.0
On Wednesday 02 June 2010 17:57:08 Jason Moxham wrote:
> This hasent happened again so it lo
This hasent happened again so it looks like a transient fault , it doesn't
look like a nfs error , and running multiple threads(and two builds 32,64 at
once) and everything runs fine , should be finished soon
On Wednesday 02 June 2010 14:43:41 Jason Moxham wrote:
> I just compiled it a
Looks good , there are only 2 or 3 real errors
your cleo and iras errors are because you need to get icc in your path , you
will hit 1 real error then , but we can easily fix that.
for lena and flavius gcc34 doesn't have a g++
gcc54 has a broken c++
gcc42 has a broken c++ and there is no way
On Wednesday 02 June 2010 15:23:39 Jason Moxham wrote:
> /home/jasonmoxham/mpir/branches/test_stuff/../../../sourcecode/mpir-2.1.0/m
>pn/m4- ccas --m4=m4 icc -c99 -c -DHAVE_CONFIG_H -no-gcc -fpic -O3
> -D__GMP_WITHIN_GMP
> -I/home/jasonmoxham/mpir/branches/test_stuff/../../../sourcecod
t2 32bit passes
SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
ultrasparc-sun-solaris2.10
Compiler gcc is
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.1/configure
--prefix=/usr/local/gcc-4.4.1-sun-linker/
--with-as=/usr/ccs/bin/as --without-gnu-as --wit
ranlib .libs/libgmp.a
rm -fr .libs/libmpir.lax
rm -fr .libs/libgmp.lax
lena 64bit passes
Linux lena 2.6.32.12-115.fc12.x86_64 #1 SMP Fri Apr 30 19:46:25 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux
k102-unknown-linux-gnu
Compiler cc is
sage.math 64bit passes
Linux sage.math.washington.edu 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC
2009 x86_64 GNU/Linux
penryn-unknown-linux-gnu
Compiler gcc-3.4 is
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/3.4.6/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,pa
/home/jasonmoxham/mpir/branches/test_stuff/../../../sourcecode/mpir-2.1.0/mpn/m4-
ccas --m4=m4 icc -c99 -c -DHAVE_CONFIG_H -no-gcc -fpic -O3 -D__GMP_WITHIN_GMP
-I/home/jasonmoxham/mpir/branches/test_stuff/../../../sourcecode/mpir-2.1.0 -
DOPERATION_mode1o -I. -
I/home/jasonmoxham/mpir/branches/tes
se the same random seeds
> etc., or is this test fixed values).
>
> Bill.
>
> On 2 June 2010 04:02, Jason Moxham wrote:
> > On varro 64 we get this failure
> >
> >
> > creating t-urndmm
> > make check-TESTS
> > PASS: t-iset
> > PASS: t-
cuda1 64bit passed , there is no 32bit compiler on that platform
Linux cuda1 2.6.28-18-server #60-Ubuntu SMP Fri Mar 12 05:11:07 UTC 2010
x86_64 GNU/Linux
k10-unknown-linux-gnu
Compiler gcc is
cato 64 bit passes
Linux sca-m0n8.scsystem 2.6.18.8-sc-lustre-perfmon #1 SMP Fri Oct 24 04:04:49
EDT 2008 mips64 SiCortex ICE9B V1.0 FPU V0.1 SiCortex SC-1000 GNU/Linux
mips64el-unknown-linux-gnu
Compiler gcc is
Using built-in specs.
Target: mips64el-gentoo-linux-gnu
Configured with: /opt/sicorte
t2 64 bit passes
SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
ultrasparc-sun-solaris2.10
Compiler gcc is
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.1/configure
--prefix=/usr/local/gcc-4.4.1-sun-linker/
--with-as=/usr/ccs/bin/as --without-gnu-as --wi
't seen that failure before. Does it still break with -O2 or less
> (is this even reliable - I mean will it use the same random seeds
> etc., or is this test fixed values).
>
> Bill.
>
> On 2 June 2010 04:02, Jason Moxham wrote:
> > On varro 64 we get this failure
>
compilers in our test script , whereas I know some are broken but I
couldn't remember which ones , and the only notes I kept were "gcc is broken
on this machine" with saying which version :( duh
Note how it fails the t-scanf test , but only if we build with c++
On Wednesday 02
I'm testing on cato,varro(64 & 32) and have done
atom 64bit
Linux box1 2.6.29.6 #2 SMP Mon Aug 17 11:58:18 CDT 2009 x86_64 Intel(R)
Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux
atom-unknown-linux-gnu
Compiler gcc is
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.3.3/specs
Tar
n ticket by Michael Abshoff to update to 6.2.2: :-)
>
> http://trac.sagemath.org/sage_trac/ticket/5847
>
> Bill.
>
> On 2 June 2010 02:54, Jason Moxham wrote:
> > I had forgotten about this , gmp-ecm-6.2.1 is 2 years old , what is it
> > doing in sage ? :) , they fixed
I had forgotten about this , gmp-ecm-6.2.1 is 2 years old , what is it doing
in sage ? :) , they fixed it in a later release , perhaps about a year ago
Jason
On Wednesday 02 June 2010 02:46:58 Bill Hart wrote:
> On 2 June 2010 02:40, William Stein wrote:
> > Hi,
> >
> > Building Sage fails wit
On Tuesday 01 June 2010 21:25:47 you wrote:
> Hi Jason,
>
> On Wed, Jun 2, 2010 at 4:39 AM, Jason Moxham
wrote:
> > can you build make tune with just
> > cd tune
> > make clean
> > make tune
> >
> > ie not using -j etc , We have had problems before
uns make check for yasm , whereas tarball does not , plus of course if
make dist has missed any files.
> Bill.
>
> On 1 June 2010 21:25, Minh Nguyen wrote:
> > Hi Jason,
> >
> > On Wed, Jun 2, 2010 at 4:39 AM, Jason Moxham
wrote:
> >> can you build make tune
1 - 100 of 487 matches
Mail list logo
