On Apr 21, 3:29 pm, mabshoff wrote:
> On Apr 21, 1:12 pm, Jason Moxham wrote:
>
> > All the machines on skynet that have compilers installed are OK
>
> > We are set to go :)
>
> I reported the problem on menas to Mariah yesterday and I got an email
> earlier today that it was fixed. The proble
On Apr 21, 1:12 pm, Jason Moxham wrote:
> All the machines on skynet that have compilers installed are OK
>
> We are set to go :)
I reported the problem on menas to Mariah yesterday and I got an email
earlier today that it was fixed. The problem was that binutils 2.19-1
did no longer function
Thanks.
2009/4/21 Jason Moxham :
>
>
> Done
>
>
> On Tuesday 21 April 2009 22:26:28 Bill Hart wrote:
>> Could you run autoconf and automake. I've updated the version numbers
>> in gmp-h.in and binary numbers in Makefile.am but when I do make dist,
>> it gives me mpir-1.1.tar.gz not mpir-1.1.1.tar
Done
On Tuesday 21 April 2009 22:26:28 Bill Hart wrote:
> Could you run autoconf and automake. I've updated the version numbers
> in gmp-h.in and binary numbers in Makefile.am but when I do make dist,
> it gives me mpir-1.1.tar.gz not mpir-1.1.1.tar.gz, so I think the
> automake on sage.math is
Could you run autoconf and automake. I've updated the version numbers
in gmp-h.in and binary numbers in Makefile.am but when I do make dist,
it gives me mpir-1.1.tar.gz not mpir-1.1.1.tar.gz, so I think the
automake on sage.math isn't doing anything.
Bill.
2009/4/21 Jason Moxham :
>
>
> All the
All the machines on skynet that have compilers installed are OK
We are set to go :)
On Tuesday 21 April 2009 21:00:33 you wrote:
> On Tuesday 21 April 2009 17:47:23 Bill Hart wrote:
> > Great, so we can do 1.1.1.
> >
> > Let's do the following:
> >
> > * I'll issue a release candidate (hopeful
On Tuesday 21 April 2009 17:47:23 Bill Hart wrote:
> Great, so we can do 1.1.1.
>
> Let's do the following:
>
> * I'll issue a release candidate (hopefully later today).
> * Jeff could you verify that the release candidate works on your
> machine as expected.
> * Jeff could you also check the buil
I believe one of those boxes is actually broken atm. I recall Michael
saying something went wrong with menas. I'll ask him about fulvia when
I see him.
Bill.
2009/4/21 Jason Moxham :
>
> On Tuesday 21 April 2009 17:47:23 Bill Hart wrote:
>> Great, so we can do 1.1.1.
>>
>> Let's do the following
On Tuesday 21 April 2009 17:47:23 Bill Hart wrote:
> Great, so we can do 1.1.1.
>
> Let's do the following:
>
> * I'll issue a release candidate (hopefully later today).
> * Jeff could you verify that the release candidate works on your
> machine as expected.
> * Jeff could you also check the buil
On Tue, Apr 21, 2009 at 12:47 PM, Bill Hart wrote:
> Let's do the following:
>
> * I'll issue a release candidate (hopefully later today).
> * Jeff could you verify that the release candidate works on your
> machine as expected.
> * Jeff could you also check the build proceeds on Windows on the
Superb!!
2009/4/21 Jeff Gilchrist :
>
> On Tue, Apr 21, 2009 at 12:47 PM, Jason Moxham
> wrote:
>
>> Here's the new config.guess
>>
>> As this the only part we have changed ,
>> just testing ./config.guess returns the correct cpu will be sufficient
>
> Yes it works, woohoo!
>
> Returns: penryn-u
On Tue, Apr 21, 2009 at 12:47 PM, Jason Moxham
wrote:
> Here's the new config.guess
>
> As this the only part we have changed ,
> just testing ./config.guess returns the correct cpu will be sufficient
Yes it works, woohoo!
Returns: penryn-unknown-linux-gnu
Just because this system is so crazy
Great, so we can do 1.1.1.
Let's do the following:
* I'll issue a release candidate (hopefully later today).
* Jeff could you verify that the release candidate works on your
machine as expected.
* Jeff could you also check the build proceeds on Windows on the
machines you'd like to test on as we
Here's the new config.guess
As this the only part we have changed ,
just testing ./config.guess returns the correct cpu will be sufficient
Thanks
Jason
On Tuesday 21 April 2009 17:15:39 Jason Moxham wrote:
> On Tuesday 21 April 2009 16:04:00 Jeff Gilchrist wrote:
> > On Tue, Apr 21, 2009 at 10
On Tuesday 21 April 2009 16:04:00 Jeff Gilchrist wrote:
> On Tue, Apr 21, 2009 at 10:19 AM, Jason Moxham
>
> wrote:
> > This is getting stranger , jeff1.c is or perhaps I should say supposed to
> > be exactly the same same as mpir generated {dummy}32.c
> >
> > Can you a diff for us
>
> This does
On Tue, Apr 21, 2009 at 10:19 AM, Jason Moxham
wrote:
> This is getting stranger , jeff1.c is or perhaps I should say supposed to be
> exactly the same same as mpir generated {dummy}32.c
>
> Can you a diff for us
This does not make any sense. You are right the only difference is
that you added
On Tuesday 21 April 2009 15:15:28 Jeff Gilchrist wrote:
> On Tue, Apr 21, 2009 at 8:01 AM, Jason Moxham
wrote:
> > Ok , I'll send a a few c files , and if you can try each one , and let
> > us know when they start working , or a different error pops up.
> > heres the first one
>
> jeff1.c:
Th
On Tue, Apr 21, 2009 at 8:01 AM, Jason Moxham wrote:
> Ok , I'll send a a few c files , and if you can try each one , and let us
> know when they start working , or a different error pops up.
> heres the first one
jeff1.c:
jeff1.c:9: warning: return type defaults to ‘int’
jeff1.c: In func
On Tuesday 21 April 2009 13:01:09 Jason Moxham wrote:
> On Tuesday 21 April 2009 12:35:35 Jeff Gilchrist wrote:
> > On Tue, Apr 21, 2009 at 7:10 AM, Jason Moxham
>
> wrote:
> > > We've got to narrow this down
> > >
> > > we know it not the asm file
> > > try swapping gmp's c file for mpir c file a
On Tuesday 21 April 2009 13:01:09 Jason Moxham wrote:
> On Tuesday 21 April 2009 12:35:35 Jeff Gilchrist wrote:
> > On Tue, Apr 21, 2009 at 7:10 AM, Jason Moxham
>
> wrote:
> > > We've got to narrow this down
> > >
> > > we know it not the asm file
> > > try swapping gmp's c file for mpir c file a
On Tuesday 21 April 2009 12:35:35 Jeff Gilchrist wrote:
> On Tue, Apr 21, 2009 at 7:10 AM, Jason Moxham
wrote:
> > We've got to narrow this down
> >
> > we know it not the asm file
> > try swapping gmp's c file for mpir c file and visa versa and see if we
> > can determine if it's the c file or t
It might be worth trying three versions of the C code:
1) just main with cpuid and check for the specific model number of
Jeff's machine and print core2
2) number 1 with stringinzing macro defined
3) number 1 with stringinzing done directly, no macro
And see if any fail.
Bill.
2009/4/21 Jeff G
On Tue, Apr 21, 2009 at 7:10 AM, Jason Moxham wrote:
> We've got to narrow this down
>
> we know it not the asm file
> try swapping gmp's c file for mpir c file and visa versa and see if we can
> determine if it's the c file or the script config.guess
It is the C file. If I edit the config.gue
We've got to narrow this down
we know it not the asm file
try swapping gmp's c file for mpir c file and visa versa and see if we can
determine if it's the c file or the script config.guess
Thanks
Jason
Clutching at straws
On Tuesday 21 April 2009 11:06:39 Jeff Gilchrist wrote:
> On Tue, Apr
On Tue, Apr 21, 2009 at 2:20 AM, Jason Moxham wrote:
> Your attatched gmp dummy32bit asm file is exactly the same as mpir dummy32bit
> asm file , so it must be either our C file , which has only one main , or how
> we call the compiler , again exactly the same as gmp
>
> I have NO IDEA whats goi
On Tuesday 21 April 2009 00:49:23 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 3:35 PM, Jason Moxham
wrote:
> >> cc -c jeff32.s jeff32.c gives no errors
> >> but linking it does. gcc gives errors as well.
> >
> > that because your gcc is 64 bit
>
> Of course, should have thought of that.
>
>
On Mon, Apr 20, 2009 at 3:35 PM, Jason Moxham wrote:
>> cc -c jeff32.s jeff32.c gives no errors
>> but linking it does. gcc gives errors as well.
>
> that because your gcc is 64 bit
Of course, should have thought of that.
> gcc on a 32bit K7 compiles those files you attached No problem
>
> gmp
On Monday 20 April 2009 19:42:48 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 2:29 PM, Jason Moxham
wrote:
> > So
> > cc jeff32.s jeff32.c -o test1
> > gives no errors
>
> cc -c jeff32.s jeff32.c gives no errors
> but linking it does. gcc gives errors as well.
that because your gcc is 64 bi
On Mon, Apr 20, 2009 at 2:29 PM, Jason Moxham wrote:
> So
> cc jeff32.s jeff32.c -o test1
> gives no errors
cc -c jeff32.s jeff32.c gives no errors
but linking it does. gcc gives errors as well.
> comment out this line
> rm -f ${dummy}64.s ${dummy}64.o ${dummy}64.c ${dummy}32.s ...
> so we do
On Monday 20 April 2009 18:35:19 Jeff Gilchrist wrote:
> I'm not sure what is going on but I can't reproduce that two main
> error. If you look at the last part of config.guess with some of my
> new debug code inserted:
>
> NOW TRYING AGAIN
> HERE 0 : cc
> dummy-423232.c:8: warning: return t
Thanks , I dont know what else to do , I dont know why we have multiply
definitions of main , it doesn't make sense , the other warnings/error are
normal/expected
On Monday 20 April 2009 18:13:59 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 1:04 PM, Jason Moxham
wrote:
> > replacing the
I'm not sure what is going on but I can't reproduce that two main
error. If you look at the last part of config.guess with some of my
new debug code inserted:
NOW TRYING AGAIN
HERE 0 : cc
dummy-423232.c:8: warning: return type defaults to âintâ
dummy-423232.c: In function âmainâ:
dummy-42323
On Mon, Apr 20, 2009 at 1:04 PM, Jason Moxham wrote:
>
> replacing the include with inline ,
> I'm getting desperate , the previous error said the function have two
> mains!!!
dummy32.s is
.globl cpuid
.globl _cpuid
cpuid:
_cpuid:
pushl %esi
pushl %ebx
mo
replacing the include with inline ,
I'm getting desperate , the previous error said the function have two
mains!!!
On Monday 20 April 2009 15:14:51 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 10:11 AM, Jason Moxham
>
> wrote:
> > here's another one with even more debug info in it
>
> Her
here's another one with even more debug info in it
thanks
jason
On Monday 20 April 2009 15:01:28 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 7:45 AM, Jason Moxham
wrote:
> > can you try this one , which has some some debug info
>
> Here is the output:
>
> dummy-2833664.s: Assembler message
On Mon, Apr 20, 2009 at 10:11 AM, Jason Moxham
wrote:
> here's another one with even more debug info in it
Here is the even more output:
dummy32.s is
.globl cpuid
.globl _cpuid
cpuid:
_cpuid:
pushl %esi
pushl %ebx
movl 16(%esp),%eax
.byte 0x0f
I've copied the subadd_n files across from mpn/x86_64w/core2 and
mpn/x86_64w/amd64 to mpir-1.1 ready to release 1.1.1 when we sort out
the config.guess issue.
No word from Burcin on the issue he reported, so that is going to be
difficult to sort out. I'm pretty sure it is miscompiled due to
optim
On Mon, Apr 20, 2009 at 7:45 AM, Jason Moxham wrote:
> can you try this one , which has some some debug info
Here is the output:
dummy-2833664.s: Assembler messages:
dummy-2833664.s:5: Error: bad register name `%rbx'
dummy-2833664.s:6: Error: bad register name `%rsi'
dummy-2833664.s:9: Error:
can you try this one , which has some some debug info
On Monday 20 April 2009 12:25:03 Jeff Gilchrist wrote:
> On Mon, Apr 20, 2009 at 2:39 AM, Jason Moxham
wrote:
> > Heres is the new config.guess that should work with all compilers
> >
> > Jeff could you try this out please
> > Standard mpir-
On Mon, Apr 20, 2009 at 2:39 AM, Jason Moxham wrote:
> Heres is the new config.guess that should work with all compilers
>
> Jeff could you try this out please
> Standard mpir-1.1.0 + attached , delete all previous changes
Running configure I get:
x86_64-unknown-linux-gnu
./config.guess
x86_64
Heres is the new config.guess that should work with all compilers
Jeff could you try this out please
Standard mpir-1.1.0 + attached , delete all previous changes
thanks
Jason
On Saturday 18 April 2009 06:44:35 Jason Moxham wrote:
> On Saturday 18 April 2009 05:09:56 Bill Hart wrote:
> > I gue
Thanks Jeff. We do test on linux with quite a few machines, but it'd
be good to add yours to the official list. The Windows machines will
certainly be helpful. I'm sure Brian will appreciate the help with the
Windows testing, as at present he is doing it all himself.
As Sage is currently porting
On Fri, Apr 17, 2009 at 11:33 PM, Bill Hart wrote:
> 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 expect as much
> testing as usual there. Jeff, would you like to volunteer to offer
> testing on certain machines for coming
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 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
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
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
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-
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
On Thursday 16 April 2009 15:09:23 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 9:57 AM, Jason Moxham
wrote:
> > and
> > cc -v
> > on both systems is ?
>
> Non-working system:
>
> pathcc -Wall -TENV:simd_zmask=OFF -TENV:simd_imask=OFF
> -TENV:simd_omask=OFF -O3 -OPT:Ofast -fno-math-errno
> pa
-- Forwarded Message --
Subject: Re: [mpir-devel] Re: MPIR 1.1.0 released!!
Date: Thursday 16 Apr 2009
From: Jeff Gilchrist
To: Jason Moxham
On Thu, Apr 16, 2009 at 5:28 PM, Jason Moxham
wrote:
> can you try this
> this is the latest config.sub and guess rena
Could the changes I made to acinclude.m4 affect this? The effect of
which is to not recognise pathcc as a gcc compiler (otherwise
autotools overrides the compiler options for pathcc with the ones for
gcc and pathcc proceeds to screw up the build because it can't handle
the -02 optimisation on MIPS
Ahh, great. We have our developers working on a solution as we speak:
http://energycrisis.co.za/wp-content/uploads/2008/01/helpdesk.jpg
Bill.
2009/4/16 Jeff Gilchrist :
>
> On Thu, Apr 16, 2009 at 9:57 AM, Jason Moxham
> wrote:
>
>> and
>> cc -v
>> on both systems is ?
>
> Non-working system:
On Thu, Apr 16, 2009 at 9:57 AM, Jason Moxham wrote:
> and
> cc -v
> on both systems is ?
Non-working system:
pathcc -Wall -TENV:simd_zmask=OFF -TENV:simd_imask=OFF
-TENV:simd_omask=OFF -O3 -OPT:Ofast -fno-math-errno
pathcc: no input files
For general help: pathcc --help
To search help: pathcc
and
cc -v
on both systems is ?
On Thursday 16 April 2009 14:55:30 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 9:53 AM, Jason Moxham
wrote:
> > Can you try this one
>
> From the non-working system:
>
> configfsf_guess is ./configfsf.guess
> cpuid_c_path is ./cpuid.c
> cc for build is
> h
On Thu, Apr 16, 2009 at 9:53 AM, Jason Moxham wrote:
> Can you try this one
>From the non-working system:
configfsf_guess is ./configfsf.guess
cpuid_c_path is ./cpuid.c
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
dummy-44401.s: Assemb
Can you try this one
thanks
On Thursday 16 April 2009 14:46:54 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 8:48 AM, Jason Moxham
wrote:
> > Can you running this config.guess
>
> Running this modified file on my Xeon system that works I get:
>
> configfsf_guess is ./configfsf.guess
> cpuid
Yeah, I suspect it is something to do with the way all this happens
pre-configure. I'm sure we are nearly at the bottom of it now.
Bill.
2009/4/16 Jeff Gilchrist :
>
> On Thu, Apr 16, 2009 at 9:41 AM, Bill Hart
> wrote:
>
>> Looks to not be using gcc. It's using the Pathscale compiler and
>> a
On Thu, Apr 16, 2009 at 8:48 AM, Jason Moxham wrote:
> Can you running this config.guess
Running this modified file on my Xeon system that works I get:
configfsf_guess is ./configfsf.guess
cpuid_c_path is ./cpuid.c
dummy-195222.c:11: warning: return type defaults to ‘int’
In file included from
On Thu, Apr 16, 2009 at 9:41 AM, Bill Hart wrote:
> Looks to not be using gcc. It's using the Pathscale compiler and
> apparently it is a 32 bit assembler or maybe even an assembler for a
> non-x86 machine.
>
> Now the question is, why?
gcc uses gcc on the system
cc uses pathscale, so is config
Looks to not be using gcc. It's using the Pathscale compiler and
apparently it is a 32 bit assembler or maybe even an assembler for a
non-x86 machine.
Now the question is, why?
Bill.
2009/4/16 Jeff Gilchrist :
>
> On Thu, Apr 16, 2009 at 8:48 AM, Jason Moxham
> wrote:
>> Can you running this
On Thu, Apr 16, 2009 at 8:38 AM, Bill Hart wrote:
> Michael Abshoff suggested perhaps the compiler on this machine
> requires, or objects to -m64.
>
> Try compiling it with:
>
> gcc -m64 test.c -o test
>
> and with
>
> gcc test.c -o test
>
> Do both work?
They both compile no warnings/errors an
On Thu, Apr 16, 2009 at 8:48 AM, Jason Moxham wrote:
> Can you running this config.guess
configfsf_guess is ./configfsf.guess
cpuid_c_path is ./cpuid.c
dummy-314631.s: Assembler messages:
dummy-314631.s:5: Error: bad register name `%rbx'
dummy-314631.s:6: Error: bad register name `%rsi'
dummy-31
Can you running this config.guess
thanks
On Thursday 16 April 2009 13:23:34 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 8:18 AM, Bill Hart
wrote:
> > What is the result of
> > gcc -v
>
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --ma
That all looks ok. I don't see anything weird there.
Michael Abshoff suggested perhaps the compiler on this machine
requires, or objects to -m64.
What happens if you compile and run the following program (test.c say):
#include
int main(void)
{
printf("hello\n");
return 0;
}
Try compili
On Thu, Apr 16, 2009 at 8:18 AM, Bill Hart wrote:
> What is the result of
> gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --w
It's really hard to imagine how that stuff breaks anything. It is
almost as if configure finds a gcc, but config.guess cannot.
What is the result of
gcc -v
on this system. Just to make sure it exists and is not really weird.
Dunno, I'm grasping at straws really
Bill.
2009/4/16 Jason Moxha
On Thursday 16 April 2009 12:55:23 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 7:42 AM, Jason Moxham
wrote:
> > can you replace cpuid.c in the main directory , and run config.guess for
> > us it should output model,family,etc
> >
> > dont try and configure mpir with this though
>
> Sorry, it
On Thu, Apr 16, 2009 at 7:58 AM, Jason Moxham wrote:
> yeah , your right.
> What distribution is it ?
It is a CentOS 5 based distribution. The kernel right now is:
Linux 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux
I think it started off as CentOS 5.1, n
On Thursday 16 April 2009 12:55:23 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 7:42 AM, Jason Moxham
wrote:
> > can you replace cpuid.c in the main directory , and run config.guess for
> > us it should output model,family,etc
> >
> > dont try and configure mpir with this though
>
> Sorry, it
On Thu, Apr 16, 2009 at 7:42 AM, Jason Moxham wrote:
> can you replace cpuid.c in the main directory , and run config.guess for us
> it should output model,family,etc
>
> dont try and configure mpir with this though
Sorry, it still just outputs:
x86_64-unknown-linux-gnu
Maybe that is the proble
can you replace cpuid.c in the main directory , and run config.guess for us
it should output model,family,etc
dont try and configure mpir with this though
thanks
Jason
penryn/core2 differences are very minor at the moment , just lshift,gmp-mparam
On Thursday 16 April 2009 12:30:42 Jeff Gilchr
On Thu, Apr 16, 2009 at 6:51 AM, Jason Moxham wrote:
> Could you run config.guess from gmp-4.3.0
It is reporting:
core2-unknown-linux-gnu
So when I force config to use --build=core2-pc-linux-gnu I get much
better results (as expected):
Intel Xeon E5405 @ 2.0GHz (Family 6, Model 23, Stepping 6
Could you run config.guess from gmp-4.3.0
thanks
jason
On Thursday 16 April 2009 11:27:13 Jeff Gilchrist wrote:
> On Thu, Apr 16, 2009 at 12:44 AM, Bill Hart
wrote:
> > Could you remove the following bit from line 738 of config.guess
> >
> >>/dev/null
> >
> > and run ./config.guess again for
This is just really, really bizarre. I'm afraid I'm *completely*
stumped. I don't even know what to suggest next.
Anyone else have any ideas?
Bill.
2009/4/16 Jeff Gilchrist :
> On Thu, Apr 16, 2009 at 12:44 AM, Bill Hart
> wrote:
>
>> Could you remove the following bit from line 738 of config
On Thursday 16 April 2009 04:26:34 Bill Hart wrote:
> If cpuid.c doesn't compile then ./configure builds with x86_64-
>
> So it looks like that is not compiling on Jeff's machine.
>
> Could stringinzing be missing?
>
./configure does have a test for stringinzing
which should define this
#def
Hi Jeff,
Could you remove the following bit from line 738 of config.guess
>/dev/null
and run ./config.guess again for us and let us know the output. This
should give us sufficient information about what is going wrong.
Bill.
2009/4/16 Bill Hart :
> If cpuid.c doesn't compile then ./configure
If cpuid.c doesn't compile then ./configure builds with x86_64-
So it looks like that is not compiling on Jeff's machine.
Could stringinzing be missing?
Bill.
2009/4/16 Bill Hart :
> Still scratching my head.
>
> Is there any chance you are using some kind of virtualisation or
> vmware or
Still scratching my head.
Is there any chance you are using some kind of virtualisation or
vmware or something on that machine. I mean that probably still
wouldn't explain it, but we have had some misidentifications with kvm
for example (though in that case /proc/cpuinfo clearly shows the wrong
v
cpuinfo looks OK
can you post the output from
/mpir-1.1/config.guess
thanks
Jason
On Thursday 16 April 2009 02:16:44 Jeff Gilchrist wrote:
> On Wed, Apr 15, 2009 at 8:50 PM, Bill Hart
wrote:
> > So yeah, the question is, how on earth did it misdetect that model.
> > The code looks tota
On Wed, Apr 15, 2009 at 8:50 PM, Bill Hart wrote:
> So yeah, the question is, how on earth did it misdetect that model.
> The code looks totally solid and correct to me.
I'm sure I linked with the correct MPIR, I'm linking to the static .a
library. Here is my /proc/cpuinfo
processor : 0
Yep, I just did a benchmark and on K8 I see that is true.
So yeah, the question is, how on earth did it misdetect that model.
The code looks totally solid and correct to me.
Bill.
2009/4/16 Jason Moxham :
>
> On Thursday 16 April 2009 01:39:07 Bill Hart wrote:
>> Wait a minute. Is that really t
On Thursday 16 April 2009 01:39:07 Bill Hart wrote:
> Wait a minute. Is that really true. Shouldn't x86_64 use the assembly
> code in the x86_64 directory, which should be considerably better than
> GMP 4.2.1?
yes , it uses asm code in x86_64 dir , which is the same as 4.2.1 , pretty
much.
>
>
Wait a minute. Is that really true. Shouldn't x86_64 use the assembly
code in the x86_64 directory, which should be considerably better than
GMP 4.2.1?
Bill.
2009/4/16 Jason Moxham :
>
> On Thursday 16 April 2009 01:15:17 Jeff Gilchrist wrote:
>> On Wed, Apr 15, 2009 at 2:33 PM, Bill Hart
> wro
You can alway force a specific build with
./configure --build=penryn-unknown-linux-gnu
On Thursday 16 April 2009 01:15:17 Jeff Gilchrist wrote:
> On Wed, Apr 15, 2009 at 2:33 PM, Bill Hart
wrote:
> > As no issues with the MPIR 1.1.0 release candidate were found after
> > extensive testing, we
On Thursday 16 April 2009 01:15:17 Jeff Gilchrist wrote:
> On Wed, Apr 15, 2009 at 2:33 PM, Bill Hart
wrote:
> > As no issues with the MPIR 1.1.0 release candidate were found after
> > extensive testing, we are making release candidate 1 the final
> > release.
>
> Here are some benchmarks. With
1 - 100 of 102 matches
Mail list logo
