On Tue, Apr 29, 2025 at 12:31:29PM +0000, Yao Zi wrote: > On Mon, Apr 28, 2025 at 08:49:43AM -0600, Tom Rini wrote: > > On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote: > > > On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote: > > > > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote: > > > > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote: > > > > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <zi...@disroot.org>: > > > > > > >Clang's preprocessor may emit extra spaces for lines starting with > > > > > > >'#'. > > > > > > >Lines with these extra characters cannot be handled by Kconfig and > > > > > > >will > > > > > > >be ignored with warnings like, > > > > > > > > > > > > > > > > > > > > > > > > > Do you have an example for reprocing the issue? > > > > > > > > > > Sure, > > > > > > > > > > clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \ > > > > > configs/starfive_visionfive2_defconfig > > > > > > > > > > or a smaller example for demonstrating the behaviour, > > > > > > > > > > cat << EOF | clang -E -P -x assembler-with-cpp - > > > > > # comment line > > > > > normal line > > > > > EOF > > > > > > > > > > and you could see the strange indentation. For reproducing the exact > > > > > Kconfig warnings, > > > > > > > > > > make ARCH=riscv \ > > > > > CC='clang-19 --target=riscv64-unknown-linux-musl' \ > > > > > starfive_visionfive2_defconfig > > > > > > > > > > (Clang is called clang-19 on my machine) > > > > > > > > > > > Is there an understanding why Clang behaves in this way? > > > > > > > > > > Sadly I have no idea. I guess it may serve for improving > > > > > human-readability of the preprocessed output. > > > > > > > > This is https://github.com/llvm/llvm-project/issues/78778 > > > > > > Thanks for the reference! I did a quick search among LLVM's issues > > > before sending the patch but didn't find anything useful. > > > > > > Do you think such workaround is acceptable? It seems the link should be > > > included in commit message as well. > > > > I'd like to see if we can get llvm to fix this moving forward first. Can > > you please comment on the issue as you're hitting this now too? > > Sure it should be fixed in LLVM and I've left a comment in the issue. > > But even though it's fixed in upstream, it will be nice to have such > compatibility workarounds for some time to keep compatibile with older > Clang toolchains, about which my concern is most.
Depending on what the LLVM people say, we can say what / how long of a workaround to keep in. -- Tom
signature.asc
Description: PGP signature
