Hello Masahiro,
On di, 2014-06-10 at 21:20 +0900, Masahiro Yamada wrote:
Hi Jeroen,
On Fri, 30 May 2014 15:45:27 +0200 Jeroen Hofstee jeroen@myspectrum.nl wrote:
Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches:
- kbuild: LLVMLinux: Adapt warnings for compilation with clang
- kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc.
I have to admit I just copied these line from Kernel without testing it, just for syncing with Kernel makefiles.
As far as I tested, Clang did not recognize -fno-delete-null-pointer-checks.
It is OK with me if you rip Clang stuff off the top Makefile.
Sorry, honestly I am not familiar enough with Clang to make deeper review.
yup, it should be removed.. since with clang 3.5 trunk it actually errors. You should be able to verify it without cross target support with:
`make CC="clang -no-integrated-as" HOSTCC="clang -no-integrated-as" HOST_TOOLS_ALL=y sandbox_config tools`
and you get (with clang 3.5) "clang: error: unknown argument: '-fno-delete-null-pointer-checks'" (and yes the commit mentions warns, which more then likely is the case for clang 3.3 / 3.4). Undoing the Linux clang additions (as this patch does) makes the build work again.
Since there is no target clang support in U-boot at the moment the target warnings suppression can be removed as well, since it is just dead code at the moment and I would like to see how far we can get with actually fixing warnings, not blindly silencing them...
Regards, Jeroen