[asterisk-dev] Asterisk 13 and -march=native

[Anatoli]

Steve,

On virtualized systems -march=native sometimes doesn't work (a known bug unrelated to asterisk, qemu & gcc don't agree on processor type and required capabilities), so replace it with -march=x86-64.

Regards,
Anatoli


From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Steve Murphy
Sent: Monday, March 02, 2015 17:51
To: Asterisk Developers Mailing List
Subject: [asterisk-dev] Asterisk 13 and -march=native

Hello!
Found an interesting problem with Asterisk 13 on a cloud 
box running CentOS 6.6. It compiled, but would die with 
an illegal instruction on loading. Looking at the result, 
I saw that it was dying on the assembler instruction:
vcvtsi2sdq -0x98.....
Apparently, this cloud box is AMD opteron 64-bit, but does
not have that particular opcode supported. I see that every
file compiles with -march=native, and that this can be turned
on/off via the 'BUILD_NATIVE' compiler option in menuselect.
I looked this up in the gcc man page, and for the i386/AMD 64-bit options, I see (under -mtune):

           native
               This selects the CPU to tune for at compilation time by determining the 
               processor type of the compiling machine.  Using -mtune=native will
               produce code optimized for the local machine under the constraints of the 
               selected instruction set.  Using -march=native will enable all
               instruction subsets supported by the local machine (hence the result 
               might not run on different machines).
And, in this case, the code generated didn't even run on my own machine.
Now, I know that one simple solution to this problem is to turn off the native
compile option in menuselect. (I tried it, and it works).  I tried again, and  turned it
on,but changed the makefile rules file to use -mtune=native instead, and this also 
worked to solve this crash.

Output of "cat /proc/cpuinfo"

vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD Opteron(TM) Processor 6272                 
stepping    : 2
cpu MHz        : 2100.096
cache size    : 2048 KB
physical id    : 0
siblings    : 1
core id        : 4
cpu cores    : 1
apicid        : 0
initial apicid    : 4
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm up rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 perfctr_core perfctr_nb
bogomips    : 4200.19
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management:

On my own AMD powered workstation, I see, in one of my centos 6.6 vm's:

vendor_id    : AuthenticAMD
cpu family    : 6
model        : 6
model name    : QEMU Virtual CPU version 2.0.0
stepping    : 3
...
flags        : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up unfair_spinlock pni cx16 x2apic popcnt hypervisor lahf_lm svm abm sse4a
Now, I guess I'm suggesting that -mtune=native be used instead of -march=native, as
it will, by default, yield a working set of code on the current machine, no matter what
the possible options are, as the BUILD_NATIVE option is turned on by default (at least
in my environment), and it's not easily recognized when BUILD_NATIVE is appropriate 
and when it is not.  Running on VM's appear to give stripped-down CPU's; and such
appears to a fad that will not go away soon... But, I'm no expert. Am I being silly?
murf
-- 

Steve Murphy
ParseTree Corporation