The vst1_*_x4 built-in functions in GCC 11 produce incorrect results,
as following exanple, this patch circumvents the issue by avoiding these
functions in GCC 11 and earlier versions.

float32x2x4_t val = {{
        {0.10f, 0.20f},
        {0.30f, 0.40f},
        {0.50f, 0.60f},
        {0.70f, 0.80f}
    }};
    float result[16];

    vst1_f32_x4(result, val);

get result = {0.100000 0.200000 0.500000 0.600000 0.000000 0.000000 0.000000 0.000000}
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>

Resolved a build failure on ARM64 with GCC 11 caused by excess
elements in a vector initializer. The issue stemmed from the
`__builtin_shuffle` function, where the number of elements in
the argument vector(s) and the mask vector must match.

For more details, refer to issue #1211.
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>

Contains RVV implementations for the following Neon instructions: 

`abal`, `abdl_high`, `addw`, `addw_high`, `bcax`, `bic`, `cadd_rot270`, `cadd_rot90`, `cmla_lane`, `cmla_rot180_lane` , `cmla_rot270_lane`, `cmla_rot90_lane`, `combine`, `cvt`, `dot`, `dot_lane`, `dup_n`, `eor`, `ext`, `maxnmv`, `minnmv` , `movl` , `movn` , `qdmull` , `qshlu_n`,  `rnda`,  `rsubhn` , `shl`, `shl_n`, `shll_n`, `shr_n`, `shrn_n`, `sqadd`, `sqrt` 

Contains RVV implementations for the following Neon instructions.

`abs`, `addl`, `addl_high`, `addlv`, `addv`, `cge`, `cgt`, `cle`, `clez`, `clt`, `cnt`, `fma`, `fms`, `fms_n`, `get_high`, `get_low`, `hsub`, `mla`, `mla_n`, `mlal`, `mlal_high`, `mlal_high_n`, `mlal_n`, `mls`, `mls_n`, `mlsl`, `mlsl_high`, `mlsl_high_n`, `mlsl_n`, `qsub`, `qtbl`, `qtbx`, `rbit`, `recpe`, `rev16`, `rev32`, `rev64`, `subl`, `subl_high`, `subw`, `subw_high`, `tbl`, `tbx`

It seems GCC supports _Float16 in C++ on aarch64 since GCC 13, at least
according to my quick tests on godbolt.org.

(It was already supported in C since GCC 7.)

_Float16 on x86 requires SSE2 instruction set to be available.
References:

 * https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
 * https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point

Clang does not support _Float16 on s390x

https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

WebKit project recently imported simde 0.8.2
Since then the build for Aarch64 targeting RPi4 boards has started
giving lot of warnings related to the simde header:

  warning: "__ARM_NEON_FP" is not defined, evaluates to 0 [-Wundef]

Add a check to ensure that __ARM_NEON_FP is defined.

Related: https://bugs.webkit.org/show_bug.cgi?id=273789

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

1. For vqdmlal_s16/s32: the doubling result maybe overflow,
so need to use vqaddq_s16/32 to saturate it. As the same with
vqdmlsl_s16/32.

2. The vrdmulh family function need to use vqadd saturating
function to avoid the doubling result overflow.

3. The result of vrshl family function need to keep the sign
bit of the origin data. If a > 0 && b < 0, the result of
(a + (1 << (-b - 1))) maybe overflow into a negative value.
And in gcc/clang, >> means the arithmetic shift left, so it
will get the incorrect sign bit whithout unsigned extend value.
Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Co-authored-by: Michael R. Crusoe <crusoe@debian.org>

Many sources claim that M1 processors support SHA2, but even with
"-march=native", apple clang throws erros like

error: always_inline function 'vsha1h_u32' requires target feature 'sha2', but would be inlined into function 'simde_vsha1h_u32' that is compiled without support for 'sha2'