And I agree, I think we should clean up the whole config.guess/configfsf.sub and configure.in for a service release.
Bill. 2009/3/14 Bill Hart <goodwillh...@googlemail.com>: > OK, found the problem. Nocona now builds with core2 code. Can you > autoconf this and commit. > > 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 >>> >>> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
