labrinea wrote:
> The original situation looks something like:
>
> ```
> #include <arm_neon.h>
>
> void foo() {
> // ...
> uint8x16_t x = {};
> vreinterpretq_u8_s8(x);
> }
> ```
>
> Compiled with `clang -target aarch64-redhat-linux-gnu
> -march=-march=armv9-a+sve2+fp16+fp16fml+crypto+bf16+sm4+i8mm+sve2-bitperm+sve2-sha3+sve2-aes+sve2-sm4
> -Xclang -target-feature -Xclang -sve -c test.c` (coming from a build system
> where `-target, -march` flags are set centrally but this particular
> target/team not being able to handle SVE appended the `-Xclang` flags for
> their target)...
>
> This compiled fine in clang-17, but with the clang-19 the frontend started
> producing this confusing message (because this is a neon intrinsic, not an
> SVE one):
>
> ```
> test.cpp:5:3: error: always_inline function 'vreinterpretq_u8_s8' requires
> target feature 'sve', but would be inlined into function 'foo' that is
> compiled without support for 'sve'
> 5 | vreinterpretq_u8_s8(x);
> ```
Well, with your patch this now compiles, but the unit test demonstrates that
none of the extensions of that command line which depend on sve (like sve2,
sve2-bitperm, etc) will get disabled. I doubt this was the intention. Passing
internal frontend options with -Xclang is not recommended.
I tried modifying`reconstructFromParsedFeatures` by replacing `Enabled.reset()`
with `disable()`and `Enabled.set()` with `enable()`but that made 50 clang tests
fail with errors similar to the one you reported (mismatch between target
features of caller and callee).
https://github.com/llvm/llvm-project/pull/142236
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
