gcc gets confused by vget_lane_f32() NEON intrinsic

Bug #1166642 reported by pmeerw
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Triaged
Low
Unassigned

Bug Description

compiling with armv7-openbricks-linux-gnueabi-gcc -mfloat-abi=softfp -mfpu=neon test.c

#include <stdio.h>
#include <stdlib.h>

#include <arm_neon.h>

int main() {
    float32x2_t x = vdup_n_f32(123.0f);
    int i = 3;
    float a = vget_lane_f32(x, i);
}

results in

In file included from test.c:4:0:
/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/devpackages/staging/gcc-final/bin/../lib/gcc/armv7-openbricks-linux-gnueabi/4.6.4/include/arm_neon.h: In function 'main':
/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/devpackages/staging/gcc-final/bin/../lib/gcc/armv7-openbricks-linux-gnueabi/4.6.4/include/arm_neon.h:4956:3: error: argument must be a constant
/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/devpackages/staging/gcc-final/bin/../lib/gcc/armv7-openbricks-linux-gnueabi/4.6.4/include/arm_neon.h:4956: confused by earlier errors, bailing out

compiler used is

armv7-openbricks-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/devpackages/staging/gcc-final/bin/armv7-openbricks-linux-gnueabi-gcc-4.6.4
COLLECT_LTO_WRAPPER=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/devpackages/staging/gcc-final/bin/../libexec/gcc/armv7-openbricks-linux-gnueabi/4.6.4/lto-wrapper
Target: armv7-openbricks-linux-gnueabi
Configured with: ../configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --target=armv7-openbricks-linux-gnueabi --prefix=/usr --with-sysroot=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain/armv7-openbricks-linux-gnueabi/sysroot --with-local-prefix=/usr/local --with-gmp=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-mpfr=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-ppl=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-cloog=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-libelf=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-mpc=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain --with-as=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain/bin/armv7-openbricks-linux-gnueabi-as --with-ld=/home/pmeerw/openbricks-bct2/build/build.brettl4.eglibc/toolchain/bin/armv7-openbricks-linux-gnueabi-ld.bfd --enable-languages=c,c++ --disable-__cxa_atexit --disable-libmudflap --disable-libssp --disable-multilib --disable-gold --enable-ld --enable-plugin --enable-lto --enable-shared --enable-c99 --enable-long-long --enable-threads=posix --enable-tls --disable-nls --disable-ppl-version-check --with-fpu=neon
Thread model: posix
gcc version 4.6.4 20130205 (prerelease) (Linaro GCC 4.6-2013.02)

4.7 seems to be affected as well:
arm-linux-gnueabi-gcc-4.7 -mfloat-abi=softfp -mfpu=neon y.c
In file included from y.c:4:0:
/usr/lib/gcc/arm-linux-gnueabi/4.7/include/arm_neon.h: In function ‘main’:
/usr/lib/gcc/arm-linux-gnueabi/4.7/include/arm_neon.h:4956:3: error: argument must be a constant
/usr/lib/gcc/arm-linux-gnueabi/4.7/include/arm_neon.h:4956: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccQGwz3f.out file, please attach this to your bugreport.

arm-linux-gnueabi-gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.7/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.7.1 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-mode=thumb --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.7.1 (Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1)

Revision history for this message
Matthew Gretton-Dann (matthew-gretton-dann) wrote :

This is expected behaviour.

The prototype for vget_lane_f32(x, i) in arm_neon.h is:

__extension__ static __inline float32_t __attribute__ ((__always_inline__))
vget_lane_f32 (float32x2_t __a, const int __b);

The second parameter (__b) must be a compile time constant. (I admit this is not obvious from the header but there is no way to show this in C).

You must therefore do something like the following:

#include <stdio.h>
#include <stdlib.h>

#include <arm_neon.h>

int main() {
    float32x2_t x = vdup_n_f32(123.0f);
    float a = vget_lane_f32(x, 1);
}

Note in C you can't use a variable of type 'const int' as C does not consider that to be a compile time constant. However C++ does allow you to do: const int i = 1; a = vget_lane_f32(x, i);

Note also that the original testcase wouldn't have worked anyway as you were asking for the third lane of a vector with only two lanes.

Changed in gcc-linaro:
importance: Undecided → Low
milestone: none → backlog
status: New → Triaged
Revision history for this message
Matthew Gretton-Dann (matthew-gretton-dann) wrote :

So whilst not a bug in the strictest sense improving the documentation - either in arm_neon.h or the GCC docs to make it clear that this parameter should be a compile time constant is a valid issue.

Revision history for this message
pmeerw (pmeerw) wrote :

agree, it should be i = 0 or i = 1 in the test code (but doesn't matter)

I understand that the 2nd parameter of vget_lane_f32() should be a constant

ubuntu gcc-4.7 crashes, this is hardly 'expected behaviour'

I would expect gcc to report the error (as it does: "error: argument must be a constant") and continue processing (it does NOT: "confused by earlier errors, bailing out")

Revision history for this message
Kumar Venkataramanan (venkataramanan-kumar) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.