On Tue, Jan 19, 2016 at 3:23 PM, Khem Raj <[email protected]> wrote: > >> On Jan 19, 2016, at 1:38 PM, Andre McCurdy <[email protected]> wrote: >> >> 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? > > option 3 >
Yes, I think that's right in this case. The sh-mem-random.c test isn't really about testing neon, so falling back to C for non-neon targets seems correct. Patch sent. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
