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.
>

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
>
> 


--~--~---------~--~----~------------~-------~--~----~
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