On 26 September 2016 at 15:03, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Mon, Sep 26, 2016 at 1:48 PM, Christophe Lyon > <christophe.l...@linaro.org> wrote: >> On 26 September 2016 at 11:43, Matthew Wahab <matthew.wa...@foss.arm.com> >> wrote: >>> Hello, >>> >>> On 25/09/16 14:00, Christophe Lyon wrote: >>>>>> >>>>>> >>>>>> This patch adds the new intrinsics: >>>>>> vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16, >>>>>> vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16, >>>>>> vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16, >>>>>> vzip_f16, vzipq_f16. >>>>>> >>>>>> This patch also updates the advsimd-intrinsics testsuite to test the f16 >>>>>> variants for ARM targets. These intrinsics are only implemented in the >>>>>> ARM target so the tests are disabled for AArch64 using an extra >>>>>> condition on a new convenience macro FP16_SUPPORTED. This patch also >>>>>> disables, for the ARM target, the testsuite defined macro vdup_n_f16 as >>>>>> it is no longer needed. >>>> >>>> >>>> Since you committed this patch, I've noticed that libgcc fails to build >>>> when GCC is configured: >>>> --target arm-none-eabi and default cpu >>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages: >>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does >>>> not support ARM mode `movwlt r0,32768' >>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does >>>> not support ARM mode `movwge r0,32767' >>>> make[4]: *** [_ssaddHQ.o] Error 1 >>>> make[4]: Leaving directory >>>> >>>> `/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc' >>>> >>> >>> >>> I can't reproduce the failure, could you send the configure arguments for >>> the build. >>> >> >> If I'm not mistaken, that is: >> --target=arm-none-eabi --disable-nls --disable-libgomp >> --disable-libmudflap --disable-libcilkrts --enable-checking >> --enable-languages=c,c++ --with-newlib >> >> Maybe you've disabled multilibs? > > > I'm pretty sure I built this as part of reviewing all these patches > with --with-mutlib-list=aprofile and didnt' see any failures. Not sure > what's going on here. >
I'm not using very recent binutils, (can't remember if that's 2.25 or 2.26, and I can't easily check remotely). Maybe something changed in the assembler? > Ramana >> >>> I've tried assembling the string 'movw r0, 32768' and get the error when >>> -march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns >>> added earlier in the series need the architecture level added as a >>> precondition but I'll need to look into it. >>> >>> Matthew >> >> Thanks, >> >> Christophe
