On Tue, Jan 19, 2016 at 1:00 PM, Khem Raj <[email protected]> wrote: > >> On Jan 18, 2016, at 11:27 PM, Rongqing Li <[email protected]> wrote: >> >> 2: on qemuarma9 >> >> | arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -marm >> -mthumb-interwork >> --sysroot=/work/wr/buildarea/arm/bitbake_build/tmp/sysroots/qemuarma9 >> -DHAVE_CONFIG_H -I. >> -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/memcheck/tests >> -I../.. >> -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0 >> >> -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/include >> >> -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/coregrind >> -I../../include >> -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/VEX/pub >> -I../../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 >> -DVGPV_arm_linux_vanilla=1 -Winline -Wall -Wshadow -Wno-long-long -g >> -fno-stack-protector -O2 -pipe -g -fno-omit-frame-pointer >> -fvisibility=default -O0 -c -o sh-mem-random.o >> /work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/memcheck/tests/sh-mem-random.c >> | {standard input}: Assembler messages: >> | {standard input}:1107: Error: selected processor does not support ARM mode >> `vld1.64 {d7},[r3]' >> | {standard input}:1107: Error: selected processor does not support ARM mode >> `vst1.64 {d7},[r2]' >> | Makefile:2467: recipe for target 'sh-mem-random.o’ failed > > > So you disable neon but do not choose a particular implementation which > allows so. e.g. you should have -mtune=cortex-a9 which allows neon to be > optional > but thats probably just the semantic thing. Below code should check for > __ARM_NEON__ internal define being set as well before resorting to use neon > instructions.
It's a test app which is failing, so I think we have 3 solutions: 1) Disable tests which don't build for all supported targets (the traditional OE approach). See: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/valgrind/valgrind/remove-arm-variant-specific.patch 2) Tweak CFLAGS so that the test always compiles but fails at run-time on non-neon targets. 3) Tweak test code so that it avoids NEON instructions on non-neon targets (risk then is that the run-time test will appear to pass on non-neon targets when it should actually fail). Any preference? >> >> and the codes are below: >> >> 194 #elif defined(__linux__) && defined(__arm__) && !defined(__aarch64__) >> 195 /* On arm32, many compilers generate a 64-bit float move >> 196 using two 32 bit integer registers, which completely >> 197 defeats this test. Hence force a 64-bit NEON load and >> 198 store. I guess this will break the build on non-NEON >> 199 capable targets. */ >> 200 __asm__ __volatile__ ( >> 201 "vld1.64 {d7},[%0] ; vst1.64 {d7},[%1] " >> 202 : : "r"(arr+src), "r"(arr+dst) : "d7","memory" >> 203 ); >> 204 #else >> >> >> -Roy >> -- >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
