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-boun...@lists.digium.com [mailto:asterisk-dev-boun...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
