[gentoo-user] -march=? for this cpu

[gentoo-user] -march=? for this cpu

[Nilesh Govindrajan]

[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]

I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm 
/proc/cpuinfo = true).

But something funny, gcc -march=native -mtune=native -v -E - 2>&1 
</dev/null returns this:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: 
/var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure 
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include 
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man 
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info 
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec 
--disable-fixed-point --without-ppl --without-cloog --enable-lto 
--enable-nls --without-included-gettext --with-system-zlib 
--enable-obsolete --disable-werror --enable-secureplt --enable-multilib 
--enable-libmudflap --disable-libssp --enable-libgomp 
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python 
--enable-checking=release --disable-libgcj --enable-libstdcxx-time 
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all 
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 
p1.11, pie-0.5.2'
Thread model: posix
gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - 
-march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt 
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx 
-mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param 
l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
  /usr/include
End of search list.
# 1 "<stdin>"
<stdin>:1:0: error: CPU you selected does not support x86-64 instruction set

It is returning pentium-m as architecture, which indeed is 32bit. I'm 
presently running the VM with -march=core2, but this is very weird.

This is the /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 2
model name      : QEMU Virtual CPU version 1.0
stepping        : 3
microcode       : 0x1
cpu MHz         : 3399.998
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx 
cx16 popcnt hypervisor lahf_lm
bogomips        : 6799.99
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Any idea what should be the march/mtune value?

-- 
Nilesh Govindarajan
http://nileshgr.com


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]

Re: [gentoo-user] -march=? for this cpu

[Walter Dnes]

On Tue, Apr 09, 2013 at 09:20:00AM +0530, Nilesh Govindrajan wrote
> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm 
> /proc/cpuinfo = true).

  Is "Hetzner" a remote hosting service?  If so, ignore what I say
below, and ask them if their VMs support 64 bits.  The part below is
applicable only if you built the VMs.


> End of search list.
> # 1 "<stdin>"
> <stdin>:1:0: error: CPU you selected does not support x86-64 instruction set
> 
> It is returning pentium-m as architecture, which indeed is 32bit. I'm 
> presently running the VM with -march=core2, but this is very weird.

  Is it possible that you built the qemu (or whatever) VM with only 32
bit support?  Assuming you're using qemu, what is the output of...

emerge -pv qemu

If you're using a different VM, list the "emerge -pv" output for it.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] -march=? for this cpu

[Michael Hampicke]

Am 09.04.2013 05:50, schrieb Nilesh Govindrajan:
> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
> /proc/cpuinfo = true).
> 
> But something funny, gcc -march=native -mtune=native -v -E - 2>&1
> </dev/null returns this:
> 
> Using built-in specs.
> COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with:
> /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
> --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
> --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
> --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
> --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
> --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
> --disable-fixed-point --without-ppl --without-cloog --enable-lto
> --enable-nls --without-included-gettext --with-system-zlib
> --enable-obsolete --disable-werror --enable-secureplt --enable-multilib
> --enable-libmudflap --disable-libssp --enable-libgomp
> --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
> --enable-checking=release --disable-libgcj --enable-libstdcxx-time
> --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
> --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
> --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3
> p1.11, pie-0.5.2'
> Thread model: posix
> gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
> COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
>  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -
> -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt
> -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx
> -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param
> l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
> ignoring nonexistent directory "/usr/local/include"
> ignoring nonexistent directory
> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
>  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
>  /usr/include
> End of search list.
> # 1 "<stdin>"
> <stdin>:1:0: error: CPU you selected does not support x86-64 instruction
> set
> 
> It is returning pentium-m as architecture, which indeed is 32bit. I'm
> presently running the VM with -march=core2, but this is very weird.
> 
> This is the /proc/cpuinfo:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 2
> model name      : QEMU Virtual CPU version 1.0
> stepping        : 3
> microcode       : 0x1
> cpu MHz         : 3399.998
> cache size      : 4096 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 4
> wp              : yes
> flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx
> cx16 popcnt hypervisor lahf_lm
> bogomips        : 6799.99
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> 
> Any idea what should be the march/mtune value?
> 

I don't have any experience with Hetzner's VMs - I only use their
dedicated machines :)

But as a more generic tip, you should install gentoo in VMs only with
generic optimization. You can not safely rely on what CPU your VM will
get. Maybe in 6 months the host your vm is on crashes, and your vm will
be migrated to a new system with totally different cpu (actual hardware
cpu or the cpu configuration that qemu is going to emulate).

Re: [gentoo-user] -march=? for this cpu

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 4348 bytes --]

On Apr 9, 2013 1:16 PM, "Michael Hampicke" <gentoo-user@hadt.biz> wrote:
>
> Am 09.04.2013 05:50, schrieb Nilesh Govindrajan:
> > I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
> > /proc/cpuinfo = true).
> >
> > But something funny, gcc -march=native -mtune=native -v -E - 2>&1
> > </dev/null returns this:
> >
> > Using built-in specs.
> > COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
> >
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
> > Target: x86_64-pc-linux-gnu
> > Configured with:
> > /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
> > --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
> > --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> > --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
> > --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
> > --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
> >
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
> > --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
> > --disable-fixed-point --without-ppl --without-cloog --enable-lto
> > --enable-nls --without-included-gettext --with-system-zlib
> > --enable-obsolete --disable-werror --enable-secureplt --enable-multilib
> > --enable-libmudflap --disable-libssp --enable-libgomp
> > --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
> > --enable-checking=release --disable-libgcj --enable-libstdcxx-time
> > --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
> > --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
> > --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3
> > p1.11, pie-0.5.2'
> > Thread model: posix
> > gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
> > COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
> >  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -
> > -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt
> > -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx
> > -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param
> > l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
> > ignoring nonexistent directory "/usr/local/include"
> > ignoring nonexistent directory
> >
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
> >
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
> >  /usr/include
> > End of search list.
> > # 1 "<stdin>"
> > <stdin>:1:0: error: CPU you selected does not support x86-64 instruction
> > set
> >
> > It is returning pentium-m as architecture, which indeed is 32bit. I'm
> > presently running the VM with -march=core2, but this is very weird.
> >
> > This is the /proc/cpuinfo:
> >
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 2
> > model name      : QEMU Virtual CPU version 1.0
> > stepping        : 3
> > microcode       : 0x1
> > cpu MHz         : 3399.998
> > cache size      : 4096 KB
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 4
> > wp              : yes
> > flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> > cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx
> > cx16 popcnt hypervisor lahf_lm
> > bogomips        : 6799.99
> > clflush size    : 64
> > cache_alignment : 64
> > address sizes   : 40 bits physical, 48 bits virtual
> > power management:
> >
> > Any idea what should be the march/mtune value?
> >
>
> I don't have any experience with Hetzner's VMs - I only use their
> dedicated machines :)
>
> But as a more generic tip, you should install gentoo in VMs only with
> generic optimization. You can not safely rely on what CPU your VM will
> get. Maybe in 6 months the host your vm is on crashes, and your vm will
> be migrated to a new system with totally different cpu (actual hardware
> cpu or the cpu configuration that qemu is going to emulate).
>

One tip for me: If your VMs are 64-bit,  obviously the underlying CPU must
be 64-bit. So, setting -march=nocona should be safe (Nocona is Intel's
first AMD64-compatible CPU).

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 5647 bytes --]

Re: [gentoo-user] -march=? for this cpu

[Nilesh Govindrajan]

[-- Attachment #1: Type: text/plain, Size: 5246 bytes --]

On Tuesday 09 April 2013 12:31:44 PM IST, Pandu Poluan wrote:
>
> On Apr 9, 2013 1:16 PM, "Michael Hampicke" <gentoo-user@hadt.biz
> <mailto:gentoo-user@hadt.biz>> wrote:
> >
> > Am 09.04.2013 05:50, schrieb Nilesh Govindrajan:
> > > I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
> > > /proc/cpuinfo = true).
> > >
> > > But something funny, gcc -march=native -mtune=native -v -E - 2>&1
> > > </dev/null returns this:
> > >
> > > Using built-in specs.
> > > COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
> > >
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
> > > Target: x86_64-pc-linux-gnu
> > > Configured with:
> > > /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
> > > --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
> > > --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> > > --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
> > > --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
> > > --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
> > >
> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
> > > --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
> --disable-altivec
> > > --disable-fixed-point --without-ppl --without-cloog --enable-lto
> > > --enable-nls --without-included-gettext --with-system-zlib
> > > --enable-obsolete --disable-werror --enable-secureplt
> --enable-multilib
> > > --enable-libmudflap --disable-libssp --enable-libgomp
> > > --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
> > > --enable-checking=release --disable-libgcj --enable-libstdcxx-time
> > > --enable-languages=c,c++,fortran --enable-shared
> --enable-threads=posix
> > > --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
> > > --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3
> > > p1.11, pie-0.5.2'
> > > Thread model: posix
> > > gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
> > > COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
> > >  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -
> > > -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul
> -mpopcnt
> > > -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx
> > > -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param
> > > l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
> > > ignoring nonexistent directory "/usr/local/include"
> > > ignoring nonexistent directory
> > >
> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
> > >
> > > #include "..." search starts here:
> > > #include <...> search starts here:
> > >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> > >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
> > >  /usr/include
> > > End of search list.
> > > # 1 "<stdin>"
> > > <stdin>:1:0: error: CPU you selected does not support x86-64
> instruction
> > > set
> > >
> > > It is returning pentium-m as architecture, which indeed is 32bit. I'm
> > > presently running the VM with -march=core2, but this is very weird.
> > >
> > > This is the /proc/cpuinfo:
> > >
> > > processor       : 0
> > > vendor_id       : GenuineIntel
> > > cpu family      : 6
> > > model           : 2
> > > model name      : QEMU Virtual CPU version 1.0
> > > stepping        : 3
> > > microcode       : 0x1
> > > cpu MHz         : 3399.998
> > > cache size      : 4096 KB
> > > fpu             : yes
> > > fpu_exception   : yes
> > > cpuid level     : 4
> > > wp              : yes
> > > flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> > > cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl
> pni vmx
> > > cx16 popcnt hypervisor lahf_lm
> > > bogomips        : 6799.99
> > > clflush size    : 64
> > > cache_alignment : 64
> > > address sizes   : 40 bits physical, 48 bits virtual
> > > power management:
> > >
> > > Any idea what should be the march/mtune value?
> > >
> >
> > I don't have any experience with Hetzner's VMs - I only use their
> > dedicated machines :)
> >
> > But as a more generic tip, you should install gentoo in VMs only with
> > generic optimization. You can not safely rely on what CPU your VM will
> > get. Maybe in 6 months the host your vm is on crashes, and your vm will
> > be migrated to a new system with totally different cpu (actual hardware
> > cpu or the cpu configuration that qemu is going to emulate).
> >
>
> One tip for me: If your VMs are 64-bit,  obviously the underlying CPU
> must be 64-bit. So, setting -march=nocona should be safe (Nocona is
> Intel's first AMD64-compatible CPU).
>
> Rgds,
> --
>

Well, it's a KVM virtual machine. And I'm *currently running* it with 
-march=core2 on 64bit, but that isn't very safe because it may be 
migrated any time in case the host fails. I guess it would be best to 
use generic x86_64?
Or perhaps switch to 32bit because it's just 2 GB of RAM and it can't 
be bumped up any further (top end config).

Some search reveals that it's an upstream bug where the CPU is detected 
as pentium m which happens to be 32 bit.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]

Re: [gentoo-user] -march=? for this cpu

[Michael Hampicke]

Am 09.04.2013 14:53, schrieb Nilesh Govindrajan:
> On Tuesday 09 April 2013 12:31:44 PM IST, Pandu Poluan wrote:
>>
>> On Apr 9, 2013 1:16 PM, "Michael Hampicke" <gentoo-user@hadt.biz
>> <mailto:gentoo-user@hadt.biz>> wrote:
>> >
>> > Am 09.04.2013 05:50, schrieb Nilesh Govindrajan:
>> > > I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
>> > > /proc/cpuinfo = true).
>> > >
>> > > But something funny, gcc -march=native -mtune=native -v -E - 2>&1
>> > > </dev/null returns this:
>> > >
>> > > Using built-in specs.
>> > > COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
>> > >
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
>>
>> > > Target: x86_64-pc-linux-gnu
>> > > Configured with:
>> > > /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
>> > > --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
>> > > --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
>> > > --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
>> > > --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
>> > > --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
>> > >
>> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
>>
>> > > --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
>> --disable-altivec
>> > > --disable-fixed-point --without-ppl --without-cloog --enable-lto
>> > > --enable-nls --without-included-gettext --with-system-zlib
>> > > --enable-obsolete --disable-werror --enable-secureplt
>> --enable-multilib
>> > > --enable-libmudflap --disable-libssp --enable-libgomp
>> > > --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
>> > > --enable-checking=release --disable-libgcj --enable-libstdcxx-time
>> > > --enable-languages=c,c++,fortran --enable-shared
>> --enable-threads=posix
>> > > --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
>> > > --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3
>> > > p1.11, pie-0.5.2'
>> > > Thread model: posix
>> > > gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
>> > > COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
>> > >  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -
>> > > -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul
>> -mpopcnt
>> > > -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx
>> > > -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param
>> > > l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
>> > > ignoring nonexistent directory "/usr/local/include"
>> > > ignoring nonexistent directory
>> > >
>> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
>>
>> > >
>> > > #include "..." search starts here:
>> > > #include <...> search starts here:
>> > >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
>> > >  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
>> > >  /usr/include
>> > > End of search list.
>> > > # 1 "<stdin>"
>> > > <stdin>:1:0: error: CPU you selected does not support x86-64
>> instruction
>> > > set
>> > >
>> > > It is returning pentium-m as architecture, which indeed is 32bit. I'm
>> > > presently running the VM with -march=core2, but this is very weird.
>> > >
>> > > This is the /proc/cpuinfo:
>> > >
>> > > processor       : 0
>> > > vendor_id       : GenuineIntel
>> > > cpu family      : 6
>> > > model           : 2
>> > > model name      : QEMU Virtual CPU version 1.0
>> > > stepping        : 3
>> > > microcode       : 0x1
>> > > cpu MHz         : 3399.998
>> > > cache size      : 4096 KB
>> > > fpu             : yes
>> > > fpu_exception   : yes
>> > > cpuid level     : 4
>> > > wp              : yes
>> > > flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca
>> > > cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl
>> pni vmx
>> > > cx16 popcnt hypervisor lahf_lm
>> > > bogomips        : 6799.99
>> > > clflush size    : 64
>> > > cache_alignment : 64
>> > > address sizes   : 40 bits physical, 48 bits virtual
>> > > power management:
>> > >
>> > > Any idea what should be the march/mtune value?
>> > >
>> >
>> > I don't have any experience with Hetzner's VMs - I only use their
>> > dedicated machines :)
>> >
>> > But as a more generic tip, you should install gentoo in VMs only with
>> > generic optimization. You can not safely rely on what CPU your VM will
>> > get. Maybe in 6 months the host your vm is on crashes, and your vm will
>> > be migrated to a new system with totally different cpu (actual hardware
>> > cpu or the cpu configuration that qemu is going to emulate).
>> >
>>
>> One tip for me: If your VMs are 64-bit,  obviously the underlying CPU
>> must be 64-bit. So, setting -march=nocona should be safe (Nocona is
>> Intel's first AMD64-compatible CPU).
>>
>> Rgds,
>> -- 
>>
> 
> Well, it's a KVM virtual machine. And I'm *currently running* it with
> -march=core2 on 64bit, but that isn't very safe because it may be
> migrated any time in case the host fails. I guess it would be best to
> use generic x86_64?
> Or perhaps switch to 32bit because it's just 2 GB of RAM and it can't be
> bumped up any further (top end config).
> 
> Some search reveals that it's an upstream bug where the CPU is detected
> as pentium m which happens to be 32 bit.
> 

I use this on 64bit VMs, but maybe nocona is better?

CHOST=""x86_64-pc-linux-gnu""

CFLAGS="-march=k8 -O2 -pipe"

Re: [gentoo-user] -march=? for this cpu

[James Cloos]

>>>>> "NG" == Nilesh Govindrajan <me@nileshgr.com> writes:

NG> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
NG> /proc/cpuinfo = true).

NG> model name      : QEMU Virtual CPU version 1.0

march=native does not work on a QEMU virtual.

In the past I had success doing this on such VMs:

gcc -dM -E - </dev/null |sort >/tmp/arch-none
gcc -march=native -dM -E - </dev/null |sort >/tmp/arch-native
diff -U0 /tmp/arch-none /tmp/arch-native 

gcc-4.4 and gcc-4.5 provide useful results from the formula;
4.6 and newer do not.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-user] Re: -march=? for this cpu

[Nikos Chantziaras]

On 09/04/13 06:50, Nilesh Govindrajan wrote:
>[...]
> This is the /proc/cpuinfo:
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 2
> model name      : QEMU Virtual CPU version 1.0
>
> [...]
> Any idea what should be the march/mtune value?

Your best bet is to ask this on the qemu mailing list.

Re: [gentoo-user] Re: -march=? for this cpu

[Nilesh Govindrajan]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Thursday 11 April 2013 06:33:17 PM IST, Nikos Chantziaras wrote:
> On 09/04/13 06:50, Nilesh Govindrajan wrote:
>> [...]
>> This is the /proc/cpuinfo:
>>
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 2
>> model name      : QEMU Virtual CPU version 1.0
>>
>> [...]
>> Any idea what should be the march/mtune value?
>
> Your best bet is to ask this on the qemu mailing list.
>
>

Probably not. I learned from the qemu wiki that it can emulate various 
kinds of processors.
So, they're probably sticking with Intel inside guests irrespective of 
the host.
Also it is a gcc/qemu bug that the CPU is detected as pentium m. As 
someone posted earlier, gcc 4.4 gives core2.
But actually, even that's wrong. I changed the flag and ended up 
getting illegal instruction for many.

Thankfully I tried that on a new machine.

Presently installing Gentoo 32 bit on that new VM with -march=i686 
-mtune=native and it's working great.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]

Re: [gentoo-user] -march=? for this cpu

[Stroller]

On 11 April 2013, at 14:11, Nilesh Govindrajan wrote:
> ...Also it is a gcc/qemu bug that the CPU is detected as pentium m. As someone posted earlier, gcc 4.4 gives core2.
> But actually, even that's wrong. I changed the flag and ended up getting illegal instruction for many.

This seems to be not so rare.

I had a bug (filed upstream, now fixed) with AMD K6-2+ being detected as an Athlon by -march=native.

In my case this was easily detectable because -march=native would produce a binary of nano which would crash immediately on launch with an "illegal instruction" error.

Setting -march=i586 or -march=k6-2 would compile a nano which works just fine. So I found this easy to test, once I knew what to look for. 

This turned out to be a one or two line fix in gcc, but I wouldn't have known where to start with the fix. I was very glad of the gcc devs' help, but it took months for them to get around to it.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743

Stroller