That said, we DO compile with clang and there was no warning https://github.com/thesofproject/linux/actions/runs/5542372669/job/150108183...
Is this dependent on a specific version of clang? I'd like to make sure our tools and tests are updated.
It should not be, I can reproduce it with all the versions of clang that the kernel supports (11.x+).
Looking at your GitHub Actions files, I am not sure exporting CC works correctly so I don't think you are building with clang. If I do it
D'oh. I did not see this one coming... nice.
locally:
$ export CC=clang
$ make -j$(nproc) defconfig
$ grep -E 'CONFIG_(CC_IS|CLANG|GCC)' .config CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=130201 CONFIG_CLANG_VERSION=0 CONFIG_GCC11_NO_ARRAY_BOUNDS=y CONFIG_GCC_PLUGINS=y # CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set # CONFIG_GCC_PLUGIN_STACKLEAK is not set
$ make -j$(nproc) sound/soc/sof/intel/hda.o
$ head -1 sound/soc/sof/intel/.hda.o.cmd savedcmd_sound/soc/sof/intel/hda.o := gcc ...
This was brought up some time ago and Masahiro made a decent point that this might not be a desirable behavior change.
https://lore.kernel.org/CAK7LNAT6Yp3oemUxSst+htnmM-St8WmSv+UZ2x2XF23cw-kU-Q@...
Switching to passing CC via the actual make command should fix that.
Not quite. We generate our .config using "make defconfig" as a baseline and then "merge_config.sh" to add a bunch of fragments we need [1]. And of course the latter script does not understand CC=clang and switches back to GCC.
Looks like I painted myself in a corner for the last 5 years...Any recommendations would be welcome.
[1] https://github.com/thesofproject/kconfig/blob/master/kconfig-sof-default.sh