`-msse4.2` should produce an error when passed to inappropriate targets

[sh1boot]

Clang seems to accept (with a warning) -msse4 for any target, not just x86.

No problem, as expected:

clang-18 --target=amd64 -msse2 -c -xc /dev/null
clang-18 --target=amd64 -msse3 -c -xc /dev/null
clang-18 --target=amd64 -msse4 -c -xc /dev/null
clang-18 --target=amd64 -msse4.2 -c -xc /dev/null

Error, as expected:

$ clang-18 --target=arm64 -msse2 -c -xc /dev/null
clang-18: error: unsupported option '-msse2' for target 'arm64'
$ clang-18 --target=arm64 -msse3 -c -xc /dev/null
clang-18: error: unsupported option '-msse3' for target 'arm64'

Warning, this is unexpected behaviour:

$ clang-18 --target=arm64 -msse4 -c -xc /dev/null
clang-18: warning: argument unused during compilation: '-msse4' [-Wunused-command-line-argument]
$ clang-18 --target=arm64 -msse4.2 -c -xc /dev/null
clang-18: warning: argument unused during compilation: '-msse4.2' [-Wunused-command-line-argument]

This breaks feature detection in some cmake files which do not see a failure from clang, meaning sse4.2 appears to be available for the compilation target.

(unexpected behaviour exists for arm64 and riscv64 at least; I haven't tested others)

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: SH (sh1boot)

Clang seems to accept (with a warning) `-msse4` for any target, not just x86.

No problem, as expected:

clang-18 --target=amd64 -msse2 -c -xc /dev/null
clang-18 --target=amd64 -msse3 -c -xc /dev/null
clang-18 --target=amd64 -msse4 -c -xc /dev/null
clang-18 --target=amd64 -msse4.2 -c -xc /dev/null

Error, as expected:

$ clang-18 --target=arm64 -msse2 -c -xc /dev/null
clang-18: error: unsupported option '-msse2' for target 'arm64'
$ clang-18 --target=arm64 -msse3 -c -xc /dev/null
clang-18: error: unsupported option '-msse3' for target 'arm64'

Warning, this is unexpected behaviour:

$ clang-18 --target=arm64 -msse4 -c -xc /dev/null
clang-18: warning: argument unused during compilation: '-msse4' [-Wunused-command-line-argument]
$ clang-18 --target=arm64 -msse4.2 -c -xc /dev/null
clang-18: warning: argument unused during compilation: '-msse4.2' [-Wunused-command-line-argument]

This breaks feature detection in some cmake files which do not see a failure from clang, meaning sse4.2 appears to be available for the compilation target.

(unexpected behaviour exists for arm64 and riscv64 at least; I haven't tested others)

[topperc]

This may be related to this FIXME

// TODO: Make -msse4.2 TargetSpecific after                                      
// https://github.com/llvm/llvm-project/issues/63270 is fixed.                   
def msse4_2 : Flag<["-"], "msse4.2">, Group<m_x86_Features_Group>;

@MaskRay

[MaskRay]

Thanks for using this feature:)

-msse4.2 remains a warning as a workaround for compiler-rt/lib/tsan on macOS. I hopefully someone with macOS can investigate #63270

% rg msse4.2 compiler-rt/
compiler-rt/lib/scudo/standalone/checksum.h
15:// - for i386 & x86_64: -mcrc32 (earlier: -msse4.2)

compiler-rt/lib/scudo/standalone/CMakeLists.txt
134:# Newer compiler versions use -mcrc32 rather than -msse4.2.
138:  set_source_files_properties(crc32_hw.cpp PROPERTIES COMPILE_FLAGS -msse4.2)

compiler-rt/test/tsan/CMakeLists.txt
43:    string(APPEND TSAN_TEST_TARGET_CFLAGS " -msse4.2 ")

compiler-rt/lib/tsan/tests/CMakeLists.txt
25:append_list_if(COMPILER_RT_HAS_MSSE4_2_FLAG -msse4.2 TSAN_UNITTEST_CFLAGS)

compiler-rt/lib/tsan/rtl/CMakeLists.txt
4:append_list_if(COMPILER_RT_HAS_MSSE4_2_FLAG -msse4.2 TSAN_RTL_CFLAGS)

compiler-rt/lib/tsan/go/buildgo.sh
100:                    ARCHCFLAGS="-m64 -msse4.2"

compiler-rt/cmake/config-ix.cmake
102:check_cxx_compiler_flag("-Werror -msse4.2"   COMPILER_RT_HAS_MSSE4_2_FLAG)

[sh1boot]

I contemplated reporting this as a cmake bug, too, because what broke for me was that check_c_compiler_flag() approved the flag despite clang issuing a [warning-level] diagnostic. I can't decide if this is in agreement with cmake documentation or not, but it does cause really noisy builds (as well as broken builds).

However, if that behaviour changed I think it would also break the workaround mentioned above, so I guess in the interim I should not mention it. 🤷🏽

[sh1boot]

As a workaround for people whose cmake configurations are being poisoned by this bug; calling cmake with CFLAGS=" [...] -Werror=unused-command-line-argument" will stop it trying to enable nonsense code.

Hopefully that shouldn't conflict with whatever else is going on in the build system. I know it'll conflict when you put things like -fuse-ld=xxx in CFLAGS instead of LDFLAGS, but I guess just try to not get into that situation in the interim.

[MaskRay]

As a workaround for people whose cmake configurations are being poisoned by this bug; calling cmake with CFLAGS=" [...] -Werror=unused-command-line-argument" will stop it trying to enable nonsense code.

Hopefully that shouldn't conflict with whatever else is going on in the build system. I know it'll conflict when you put things like -fuse-ld=xxx in CFLAGS instead of LDFLAGS, but I guess just try to not get into that situation in the interim.

If you can work around #63270 (compiler-rt/lib/tsan/rtl/CMakeLists.txt for macOS), we can drop the workaround in clang driver...

[sh1boot]

I'm afraid I don't know much about how that'll work. What I'm working around is a bunch of different open source projects which use cmake's check_c_compiler_flag() for configuration, and consequently try to compile SSE4.2 optimisations on my non-x86 target, rendering them all unbuildable.