This seems relevant:
http://gmplib.org/list-archives/gmp-bugs/2007-August/000813.html
The gcc version is too close to be a coincidence I think.
Bill.
2009/4/18 Jason Moxham :
>
> On Saturday 18 April 2009 06:36:13 mabshoff wrote:
>> On Apr 17, 10:32 pm, Jason Moxham wrote:
>> > On Saturday 18
On Apr 17, 10:49 pm, Jason Moxham wrote:
> How about we set up a virtual? machine which cycles thru all available OS's
> testing sage/mpir on each one. One machine could then cover quite a few
> different configurations.
We have that already, i.e. about 18 different images running on the
same
How about we set up a virtual? machine which cycles thru all available OS's
testing sage/mpir on each one. One machine could then cover quite a few
different configurations.
On Saturday 18 April 2009 04:33:09 Bill Hart wrote:
> This was a pretty unusual release in that officially it happened o
On Saturday 18 April 2009 05:09:56 Bill Hart wrote:
> I guess the idea of doing a 32 bit test if the 64 bit code fails is
> probably a sensible one. The CPUID should still be returned correctly.
>
> I too don't want to work around every broken system. However this is a
> case that GMP gets right a
On Saturday 18 April 2009 06:36:13 mabshoff wrote:
> On Apr 17, 10:32 pm, Jason Moxham wrote:
> > On Saturday 18 April 2009 05:52:08 Bill Hart wrote:
>
>
>
> > > As got_count is 0 then it is comparing two length 0 arrays and says
> > > they are not equal. So this appears to be a problem with mem
We could special case it in the test code, I suppose. But given the
number of systems this test code passes on, it is pretty unusual.
Perhaps Burcin could valgrind the test for us (you only need to run
the individual test t-export not the whole of make check). The
t-export test function gets buil
On Apr 17, 9:09 pm, Bill Hart wrote:
> I guess the idea of doing a 32 bit test if the 64 bit code fails is
> probably a sensible one. The CPUID should still be returned correctly.
Yep, that seems like the best solution to me.
> I too don't want to work around every broken system. However this
On Apr 17, 10:32 pm, Jason Moxham wrote:
> On Saturday 18 April 2009 05:52:08 Bill Hart wrote:
> > As got_count is 0 then it is comparing two length 0 arrays and says
> > they are not equal. So this appears to be a problem with memcmp which
> > is just a C library function.
>
> memcmp may no
On Saturday 18 April 2009 05:52:08 Bill Hart wrote:
> Here is the relevant line of code:
>
> if (memcmp (got_data, data[i].want_data, got_count * data[i].size) != 0)
> {
> printf ("wrong result data\n");
> error = 1;
> }
>
> As got_count is 0 the
Here is the relevant line of code:
if (memcmp (got_data, data[i].want_data, got_count * data[i].size) != 0)
{
printf ("wrong result data\n");
error = 1;
}
As got_count is 0 then it is comparing two length 0 arrays and says
they are not equal. S
I guess the idea of doing a 32 bit test if the 64 bit code fails is
probably a sensible one. The CPUID should still be returned correctly.
I too don't want to work around every broken system. However this is a
case that GMP gets right and we don't, so I would say we should fix
it.
Do you want to
This was a pretty unusual release in that officially it happened on
the same day as 1.0.0. That is unlikely to ever happen again. However,
I am all in favour of Jeff's suggestion.
We did do a full testing cycle for linux and we asked Brian about
Windows testing, but as he had been away we didn't
I would also be interested if GMP 4.2.1 and 4.3.0 passes/fails this
test on this machine. I don't see that we've done anything differently
for this function.
Bill.
2009/4/17 Jason Moxham :
>
>
> Have you tried building sage with gmp , does that pass the tests?
>
> I've tested mpir-0.9,1.0 and 1.
On Fri, Apr 17, 2009 at 4:39 PM, Cactus wrote:
> Sadly you are right - I have not committed the subadd_n.asm file. I
> have now done this in the trunk.
>
> I am afraid that I was on holiday last week and this, combined with
> the rapid release of 1.1 after 1.0 caught me out on this one.
I was
On Apr 17, 9:01 pm, Jeff Gilchrist wrote:
> Sorry for more bad news. I have just had a chance to try 1.1.0 on
> Windows and 32bit is compiling fine, but 64bit Core2 and AMD builds
> fail.
>
> I'm getting an error that it cannot open subadd_n.asm and sure enough
> if I look in the Windows build
On Apr 17, 9:01 pm, Jeff Gilchrist wrote:
> Sorry for more bad news. I have just had a chance to try 1.1.0 on
> Windows and 32bit is compiling fine, but 64bit Core2 and AMD builds
> fail.
>
> I'm getting an error that it cannot open subadd_n.asm and sure enough
> if I look in the Windows build
On Friday 17 April 2009 21:01:52 Jeff Gilchrist wrote:
> Sorry for more bad news. I have just had a chance to try 1.1.0 on
> Windows and 32bit is compiling fine, but 64bit Core2 and AMD builds
> fail.
>
> I'm getting an error that it cannot open subadd_n.asm and sure enough
> if I look in the Win
Sorry for more bad news. I have just had a chance to try 1.1.0 on
Windows and 32bit is compiling fine, but 64bit Core2 and AMD builds
fail.
I'm getting an error that it cannot open subadd_n.asm and sure enough
if I look in the Windows build directories, sure enough that file is
missing from both
On Apr 17, 3:05 am, Dan Shumow wrote:
> I was just playing around and I was curious if it is possible to turn
> off including assembly optimizations with a pound define. I see the
> NO_ASM flag, but that appears to only work when __GNUC__ is defined.
>
> If I undef all of the HAVE_HOST_CPU_FAM
Thanks Jeff
The problem is that pathcc has been set up to default to a 32bit compiler on
the broken system. pathcc has a default config file which needs to be
changed. GMP has a work around for this.
Do we really want to workaround every broken configuration?
We could provide a warning that
that interesting , gmp fails as well , but
it look likes it tries a 32 bit version , and that passes
I'll mimic it , and see what happens
On Friday 17 April 2009 18:53:43 Jeff Gilchrist wrote:
> On Fri, Apr 17, 2009 at 8:14 AM, Jason Moxham
wrote:
> > can you put this in the gmp-4.3.0 direct
On Fri, Apr 17, 2009 at 8:13 AM, mabshoff
wrote:
> Well, "randomly" adding -m64 to CFLAGS is not a good idea since for
> example gccs on RHEL/Itanium as well as MPIS64 boxen for example blow
> up using that switch. I have never seen a 64 bit x86-64 system that
> failed, so if compilation fails w
On Fri, Apr 17, 2009 at 8:14 AM, Jason Moxham wrote:
> can you put this in the gmp-4.3.0 directory and run config.guess
> we will see what it thinks
cc for build is
host cc is
cc is
cc for build is cc
host cc is
cc is
cc for build is cc
host cc is
cc is
pathcc -Wall -TENV:simd_zmask=OFF -TENV:si
can you put this in the gmp-4.3.0 directory and run config.guess
we will see what it thinks
thanks
jason
On Friday 17 April 2009 13:08:25 Jeff Gilchrist wrote:
> On Fri, Apr 17, 2009 at 7:44 AM, Jason Moxham
wrote:
> > our config.guess uses cc which is before configure even gets to the
> > co
On Apr 17, 5:08 am, Jeff Gilchrist wrote:
Hi Jeff,
> On Fri, Apr 17, 2009 at 7:44 AM, Jason Moxham
> wrote:
> > our config.guess uses cc which is before configure even gets to the compiler
> > tests , same for gmp-4.3.0
>
> It seems gmp-4.3.0 works fine so if they are using cc, then they ar
On Fri, Apr 17, 2009 at 7:44 AM, Jason Moxham wrote:
> our config.guess uses cc which is before configure even gets to the compiler
> tests , same for gmp-4.3.0
It seems gmp-4.3.0 works fine so if they are using cc, then they are
calling pathcc on my system. Does their config.guess use any -m6
On Friday 17 April 2009 08:18:43 Bill Hart wrote:
> We should figure out:
>
> 1) Does GMP default to Core2 if it can't identify the CPU (as MPIR
> 1.0.0 does) - I don't think so. I'm pretty sure it defaults to atom.
I havent tested , but looking at the code it defaults to x86_64 , which for
gmp-
On Apr 17, 4:37 am, Jason Moxham wrote:
> Have you tried building sage with gmp , does that pass the tests?
Since we have switched away from GMP I doubt he did it and since MPIR
1.1 works I don't think it matters too much for Sage at least since we
will update today :). The box did build the v
Have you tried building sage with gmp , does that pass the tests?
I've tested mpir-0.9,1.0 and 1.1 on a linux Pentium D with no problems ,
although it was with a more modern compiler , I think gcc-4.2.4
Note: your Pentium is running as 64 bit
Does it only bomb out when sage builds it ?
Jason
On Fri, 17 Apr 2009 11:01:36 +0200
Burcin Erocal wrote:
> On Fri, 17 Apr 2009 01:50:15 -0700 (PDT)
> mabshoff wrote:
>
> > On Apr 17, 1:35 am, Burcin Erocal wrote:
>
> > > I got the following error while building Sage-3.4.1.rc3 on my 32-bit
> > > Pentium D workstation (prescott?):
> >
> >
Hi,
On Fri, 17 Apr 2009 01:50:15 -0700 (PDT)
mabshoff wrote:
> On Apr 17, 1:35 am, Burcin Erocal wrote:
> > I got the following error while building Sage-3.4.1.rc3 on my 32-bit
> > Pentium D workstation (prescott?):
>
> For the record: That version of Sage ships MPIR 1.0.rc8, 3.4.1.rc4
> wi
On Apr 17, 1:35 am, Burcin Erocal wrote:
> Hi,
Hi Burcin,
> I got the following error while building Sage-3.4.1.rc3 on my 32-bit Pentium
> D workstation (prescott?):
For the record: That version of Sage ships MPIR 1.0.rc8, 3.4.1.rc4
will ship MPIR 1.1, so no worries.
> Let me know if you
Hi,
I got the following error while building Sage-3.4.1.rc3 on my 32-bit Pentium D
workstation (prescott?):
...
PASS: t-import
wrong result data
at data[0] align=0
src "0"
src=0x0
order=1 size=1 endian=1 nail=0
want count 0
got count 0
want
got
/bin/sh: line
We should figure out:
1) Does GMP default to Core2 if it can't identify the CPU (as MPIR
1.0.0 does) - I don't think so. I'm pretty sure it defaults to atom.
2) Does it detect the CPU correctly - I think so, in this case at
least, though clearly not in other cases
3) Does it just refuse to use pa
34 matches
Mail list logo
