Well that is bizarre. It is totally fine after deleting the directory
and checking it out again. Somehow my files had gotten corrupted. It's
all good now though.

configure, make, make check all pass on sage.math.

Bill.

2009/3/14 Bill Hart <goodwillh...@googlemail.com>:
> Hmm, currently configure is well and truly broken on sage.math. Did
> something go wrong during autoconf.
>
> Bill.
>
> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>
>> On Saturday 14 March 2009 19:42:33 Bill Hart wrote:
>>> OK, can you try autotools and commit again. I went back to revision
>>> 1730 and made the changes again, this time hopefully without breaking
>>> everything else.
>>>
>>
>> done
>>
>>> Really odd it didn't tell me my revision was out of date. It usually
>>> does if commits cross in the aether.
>>>
>>
>> Mine wont let me commit unless I'm up to date
>>
>>> Bill.
>>>
>>> 2009/3/14 Bill Hart <goodwillh...@googlemail.com>:
>>> > Oh dear, I think I didn't. I'll back it out and try again.
>>> >
>>> > Bill.
>>> >
>>> > 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>> >> On Saturday 14 March 2009 19:14:50 Bill Hart wrote:
>>> >>> That's an excellent solution. Now we just need to fix linux so that it
>>> >>> still works on these systems. Oh joy!
>>> >>>
>>> >>> Bill.
>>> >>>
>>> >>> 2009/3/14 Cactus <rieman...@googlemail.com>:
>>> >>> > On Mar 14, 7:03 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote:
>>> >>> >> On Saturday 14 March 2009 18:35:32 Bill Hart wrote:
>>> >>> >> > OK, found the problem. Nocona now builds with core2 code. Can you
>>> >>> >> > autoconf this and commit.
>>> >>
>>> >> did you use the right configure.in , we seem to have lost some stuff eg
>>> >> GMPLINK
>>> >>
>>> >>> >> I can install my old autotools on another machine, in a few hours.
>>> >>> >> The new autotools require ylwrap , which I added with
>>> >>> >> automake --add-missing
>>> >>> >> ylwrap is used for parralel makes (which I certainly do)
>>> >>> >> It's put it as a symbolic link though , I could copy the file itself
>>> >>> >>
>>> >>> >> commited anyway
>>> >>> >>
>>> >>> >> > So now we need to exclude those broken models after all. :-)
>>> >>> >> >
>>> >>> >> > No need for a full round of testing. We only need to check that
>>> >>> >> > configure still works on all the machines we've tested for and
>>> >>> >> > just randomly test a few full builds.
>>> >>> >> >
>>> >>> >> > Bill.
>>> >>> >> >
>>> >>> >> > 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>> >>> >> > > On Saturday 14 March 2009 18:13:00 Bill Hart wrote:
>>> >>> >> > >> OK, but I'm still unclear why it doesn't pick up the files in
>>> >>> >> > >> the core2 directory. That is what it should do based on the
>>> >>> >> > >> code that is there. This means noconas are giving a generic C
>>> >>> >> > >> build, which I am sure Gonzalo would have complained about by
>>> >>> >> > >> now if it was the case, because he has a nocona.
>>> >>> >> > >
>>> >>> >> > > Perhaps he uses fat build? , which would think its a core2
>>> >>> >> > >
>>> >>> >> > > There some references missing in configure.in , and a shed load
>>> >>> >> > > of inconsistencies . I can fix but it means another round of
>>> >>> >> > > testing
>>> >>> >> > >
>>> >>> >> > >> Bill.
>>> >>> >> > >>
>>> >>> >> > >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>> >>> >> > >> > On Saturday 14 March 2009 18:07:59 Bill Hart wrote:
>>> >>> >> > >> >> I get:
>>> >>> >> > >> >>
>>> >>> >> > >> >> wbh...@sage:~/mpir-test$ ./configure
>>> >>> >> > >> >> --build=nocona-unknown-gnu-linux checking build system
>>> >>> >> > >> >> type... Invalid configuration
>>> >>> >> > >> >> `nocona-unknown-gnu-linux': machine `nocona-unknown-gnu' not
>>> >>> >> > >> >> recognized
>>> >>> >> > >> >> configure: error: /bin/bash ./config.sub
>>> >>> >> > >> >> nocona-unknown-gnu-linux failed
>>> >>> >> > >> >>
>>> >>> >> > >> >> I think config.sub is broken.
>>> >>> >> > >> >
>>> >>> >> > >> > whoops    linux-gnu not gnu-linux
>>> >>> >> > >> >
>>> >>> >> > >> >> Bill.
>>> >>> >> > >> >>
>>> >>> >> > >> >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>> >>> >> > >> >> > On Saturday 14 March 2009 17:59:00 Bill Hart wrote:
>>> >>> >> > >> >> >> Are you sure about that:
>>> >>> >> > >> >> >>
>>> >>> >> > >> >> >> case $host in
>>> >>> >> > >> >> >>           x86_64-*-* | i786-*-*)
>>> >>> >> > >> >> >>             path_64="x86_64/amd64 x86_64" ;;
>>> >>> >> > >> >> >>           k10-*-*)
>>> >>> >> > >> >> >>             path_64="x86_64/amd64/k10 x86_64/amd64
>>> >>> >> > >> >> >> x86_64" ;; nocona-*-* | core2-*-*)
>>> >>> >> > >> >> >> <<-------------------------------------
>>> >>> >> > >> >> >>             path_64="x86_64/core2 x86_64" ;;
>>> >>> >> > >> >> >> <<-------------------------------------
>>> >>> >> > >> >> >>         esac
>>> >>> >> > >> >> >>
>>> >>> >> > >> >> >> Seems to use the core2 code.
>>> >>> >> > >> >> >
>>> >>> >> > >> >> > try with ./configure --build=nocona-unknown-gmu-linux and
>>> >>> >> > >> >> > you get C and done on a real Pentium D as well
>>> >>> >> > >> >> >
>>> >>> >> > >> >> >> Bill.
>>> >>> >> > >> >> >>
>>> >>> >> > >> >> >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>:
>>> >>> >> > >> >> >> > On Saturday 14 March 2009 17:41:58 Jason Moxham wrote:
>>> >>> >> > >> >> >> >> Early Intel CPUs with Intel 64 lacked LAHF and SAHF
>>> >>> >> > >> >> >> >> instructions available in AMD64 until introduction of
>>> >>> >> > >> >> >> >> Pentium 4 G1 step in December 2005. LAHF and SAHF are
>>> >>> >> > >> >> >> >> load and store instructions, respectively, for certain
>>> >>> >> > >> >> >> >> status flags. These instructions are used for
>>> >>> >> > >> >> >> >> virtualization and floating-point condition handling.
>>> >>> >> > >> >> >> >>
>>> >>> >> > >> >> >> >> I'll  find out model numbers soon
>>> >>> >> > >> >> >> >
>>> >>> >> > >> >> >> > No need for MPIR-1.0.0 , all 64bit  Pentium's default
>>> >>> >> > >> >> >> > to nonoca which leads to a generic C build.
>>> >>> >> > >> >> >> >
>>> >>> >> > >> >> >> >> On Saturday 14 March 2009 17:20:25 Gonzalo Tornaria
>> wrote:
>>> >>> >> > >> >> >> >> > On Sat, Mar 14, 2009 at 1:45 PM, Jason Moxham
>>> >>> >> > >> >> >> >> > <ja...@njkfrudils.plus.com>
>>> >>> >> > >> >> >> >>
>>> >>> >> > >> >> >> >> wrote:
>>> >>> >> > >> >> >> >> > > I pretty sure all core2 cpus have lahf,sahf , it's
>>> >>> >> > >> >> >> >> > > just some Pentium D dont have it . You can test
>>> >>> >> > >> >> >> >> > > the lahf_lm feature bit in cpuid to see if it's
>>> >>> >> > >> >> >> >> > > got it
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > Tested in:
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > My laptop: model 6 / family 15 (core 2 duo T5300).
>>> >>> >> > >> >> >> >> > My desktop is family 15 / model 6 (pentium D 930).
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > The "lahf_lm" feature is present in both according
>>> >>> >> > >> >> >> >> > to /proc/cpuinfo.
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > Note that the laptop is "low end" core 2 (in the
>>> >>> >> > >> >> >> >> > sense it has no VT extensions). The pentium D is
>>> >>> >> > >> >> >> >> > "high end" (in the sense it has VT extensions ---
>>> >>> >> > >> >> >> >> > low end would be pentium D 8xx). Maybe that makes a
>>> >>> >> > >> >> >> >> > difference?
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > OTOH, the kvm 64 bit virtual cpu (kvm 72) doesn't
>>> >>> >> > >> >> >> >> > seem to know about the "lahf_lm" (meaning, it won't
>>> >>> >> > >> >> >> >> > report it in cpuid, even if the host processor has
>>> >>> >> > >> >> >> >> > it. I assume the instructions would work anyway.)
>>> >>> >> > >> >> >> >> >
>>> >>> >> > >> >> >> >> > Gonzalo- Hide quoted text -
>>> >>> >>
>>> >>> >> - Show quoted text -
>>> >>> >
>>> >>> > I have just tested my GMP assembler code (based on Pierrick Gaudry's
>>> >>> > code) for mpn_add_n and mpn_sub_n in MPIR on Core2 and it achieves
>>> >>> > the same speed as the current code
>>> >>> >
>>> >>> > So I can solve this on Windows without difficulty by simply using
>>> >>> > this code.
>>> >>> >
>>> >>> > It is very mature code so I don't see any problem in using it (I will
>>> >>> > obviously test it).
>>> >>> >
>>> >>> >    Brian
>>>
>>>
>>
>>
>> >>
>>
>

--~--~---------~--~----~------------~-------~--~----~
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://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to