Thanks Leon,
I agree it is probably an unrelated coincidence. I am also using morty. I don't have the logs around any more but the logs had -march=core2 -mtune-core2 -m32, which was correct for the build. I did wonder whether the asterisk autoconf was too clever but I think in my case it may be more a case of the compiler using core2 instructions that are not valid for atom. Regards, Chris ________________________________ From: Leon Woestenberg <l...@sidebranch.com> Sent: 16 January 2017 09:57 To: Chris Trobridge Cc: Yocto List Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom Hello Chris, Probably unrelated, but yesterday my krogoth build failed on an Atom *host/build* system. I was just about to debug this when I saw your email. The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 -m64. I am debugging this currently. Maybe check if the asterix recipe tries to be smart in a similar way? And verify the do_compile log for actual compiler options. Regards, Leon. build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0 configure: checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 ... yes checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8... yes checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8... yes "-m64 -mtune=k8 -march=k8" on gcc 5.4.0: x86_64-linux-libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe -c ../../gmp-6.1.0/cxx/osmpq.cc -fPIC -DPIC -o .libs/osmpq.o ../x86_64-linux-libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc make[2]: *** [osmpz.lo] Segmentation fault On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge <christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote: This arose building asterisk switching from 13.7 to 13.11+. The executable core dumps immediately with an illegal instruction instruction, which gdb reported as 'andn'. This is part of BMI1, which was introduced with Haswell. I am targeting a (32-bit) Z5xx Atom processor, which predates this instruction. I don't know what changed in the Asterisk build to cause this (the instruction is in some regular compiler generate code) but the compiler is still generating legal core2 code and tune-core2.inc is recommended for Atom processors: "This tune is recommended for the Intel Core 2 CPU family, including Conroe, Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond." I am still considering this output is down to some quirk in my configuration but I found that -mtune and -march options were added for Atom in GCC in 4.5, so this could be another line of attack, although I didn't find any explicit code for this in meta/meta-intel. Any ideas? My initial plan is to try to acoid the core2 tuning and then, if that helps, attempt to get atom tuning working, unless that's likely to be cause further breakages due to being unexpected. Regards, Chris -- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
