Repository navigation
arm neon broken on armv7 #81
Description
When building newer nodejs versions with llhttp 9.3.0 (e.g. nodejs v20.19.5) for armv7 using gcc 14.2.0 with node configure option --with-arm-fpu=neon it complains about a type mismatch:
../deps/llhttp/src/llhttp.c: In function 'llhttp__internal__run':
../deps/llhttp/src/llhttp.c:2645:9: note: use '-flax-vector-conversions' to permit conversions between vectors with differing element types or numbers of subparts
2645 | );
| ^
../deps/llhttp/src/llhttp.c:2643:11: error: incompatible type for argument 1 of 'vandq_u16'
2643 | vcgeq_u8(input, vdupq_n_u8(' ')),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
In file included from ../deps/llhttp/src/llhttp.c:14:
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15231:23: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15231 | vandq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2644:11: error: incompatible type for argument 2 of 'vandq_u16'
2644 | vcleq_u8(input, vdupq_n_u8('~'))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15231:39: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15231 | vandq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2646:26: error: incompatible type for argument 1 of 'vorrq_u16'
2646 | mask = vorrq_u16(mask, single);
| ^~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15343:23: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15343 | vorrq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2646:32: error: incompatible type for argument 2 of 'vorrq_u16'
2646 | mask = vorrq_u16(mask, single);
| ^~~~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15343:39: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15343 | vorrq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2648:11: error: incompatible type for argument 1 of 'vandq_u16'
2648 | vcgeq_u8(input, vdupq_n_u8(0x80)),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15231:23: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15231 | vandq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2649:11: error: incompatible type for argument 2 of 'vandq_u16'
2649 | vcleq_u8(input, vdupq_n_u8(0xff))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15231:39: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15231 | vandq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2651:26: error: incompatible type for argument 1 of 'vorrq_u16'
2651 | mask = vorrq_u16(mask, single);
| ^~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15343:23: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15343 | vorrq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2651:32: error: incompatible type for argument 2 of 'vorrq_u16'
2651 | mask = vorrq_u16(mask, single);
| ^~~~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:15343:39: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
15343 | vorrq_u16 (uint16x8_t __a, uint16x8_t __b)
| ~~~~~~~~~~~^~~
../deps/llhttp/src/llhttp.c:2652:30: error: incompatible type for argument 1 of 'vshrn_n_u16'
2652 | narrow = vshrn_n_u16(mask, 4);
| ^~~~
| |
| uint8x16_t
/home/devel/toolchain/cc/lib/gcc/arm-linux-gnueabihf/14.2.0/include/arm_neon.h:4699:25: note: expected 'uint16x8_t' but argument is of type 'uint8x16_t'
4699 | vshrn_n_u16 (uint16x8_t __a, const int __b)
| ~~~~~~~~~~~^~~
I also tried using -flax-vector-conversions, but this breaks the parser completly. I am not sure where exactly the issue is coming from.
I guess it comes from 75d26f1. Probably this commit does not work for armv7.
Activity
lal12 commentedon Sep 19, 2025
P.S. using
--with-arm-fpu=neonis irrelevant since the define__ARM_NEON__is there only dependent on the compiler support for it.