[aarch64] clang compile error, when compile a C file, however succeess when rename the file to cpp

[scoutzeng]

clang version: 19.1.1
cmake version: 4.0.1
visual studio pro 17 2022
I'm going to compile a helloworld program main.c

#include <stdio.h>
#include <arm_neon.h>

int main() {
	int64x2_t a = { 1,2 };
	const int b = 1;
	int64x2_t res = vshlq_n_s64(a, b);
	return 0;
}

on x64 windows platform, i use cmake -S ../src -B . -G "Visual Studio 17 2022" -A ARM64 cmake --build . commands to compile, however compiler output an error error C2057: expected constant expression. After that i just change the main.c to main.cpp, then everythig is ok. I just wonder what happend? why i can't name it as a C file.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (scoutzeng)

clang version: 19.1.1 cmake version: 4.0.1 visual studio pro 17 2022 I'm going to compile a helloworld program main.c ```c #include <stdio.h> #include <arm_neon.h>

int main() {
int64x2_t a = { 1,2 };
const int b = 1;
int64x2_t res = vshlq_n_s64(a, b);
return 0;
}

on x64 windows platform, i use `cmake  -S ../src -B . -G "Visual Studio 17 2022" -A ARM64`  `cmake --build .` commands to compile, however compiler output an error `error C2057: expected constant expression`. After that i just change the main.c to main.cpp, then everythig is ok. I just wonder what happend? why i can't name it as a C file.
</details>

[EugeneZelenko]

Could you please try 20 or main branch? https://godbolt.org should be helpful.

[efriedma-quic]

"error C2057" is an MSVC error code. Are you sure you're actually using clang?

[zygoloid]

Clang also rejects this when compiling as a C source file, as does GCC. And the compilers are all correct to do so: vshlq_n_s64 requires an integer constant expression as its second argument, and the rules for integer constant expressions in C are quite strict. Unlike in C++, a local variable of type const int cannot be used in an integer constant expression in C.

You can work around that C limitation by using an enum (enum { b = 1 };) or a macro (#define b 1) instead of a variable.

[scoutzeng]

Clang also rejects this when compiling as a C source file, as does GCC. And the compilers are all correct to do so: vshlq_n_s64 requires an integer constant expression as its second argument, and the rules for integer constant expressions in C are quite strict. Unlike in C++, a local variable of type const int cannot be used in an integer constant expression in C.

You can work around that C limitation by using an enum (enum { b = 1 };) or a macro (#define b 1) instead of a variable.

ARM64 GCC compiler can compile success even b is not wrapped with const keyword.

[zygoloid]

Ah, interesting. Looks like GCC allows this code when optimizing, but not otherwise. Perhaps we should consider applying our "GCC-like constant folding" to this situation too, to improve compatibility, at least in GNU mode. Reopening for further consideration.

[shafik]

Ah, interesting. Looks like GCC allows this code when optimizing, but not otherwise. Perhaps we should consider applying our "GCC-like constant folding" to this situation too, to improve compatibility, at least in GNU mode. Reopening for further consideration.

Accepting code based on optimization level does not feel particularly user friendly and feels fragile. Especially since there are workarounds available that are viable alternatives.

I would like stronger motivation than another implementation allows it.

Just like we generally don't do diagnostics from the backend b/c they are fragile.

[erichkeane]

Ah, interesting. Looks like GCC allows this code when optimizing, but not otherwise. Perhaps we should consider applying our "GCC-like constant folding" to this situation too, to improve compatibility, at least in GNU mode. Reopening for further consideration.

Accepting code based on optimization level does not feel particularly user friendly and feels fragile. Especially since there are workarounds available that are viable alternatives.

I would like stronger motivation than another implementation allows it.

Just like we generally don't do diagnostics from the backend b/c they are fragile.

I think the suggestion was for us to still be incompatible with GCC here, except in the more permissive manner. We can allow this in both unopt and opt mode in C by reverting to the "GCC-like constant folding" that @zygoloid mentions. We'd still be incompatible, but at least we'd be permissive rather than stricter for little reason.