Re: [PATCH -v3] kbuild: Add extra gcc checks

[Arnaud Lacombe]

Hi,

On Sun, Feb 20, 2011 at 11:37 PM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Sun, Feb 20, 2011 at 10:26:13PM -0500, Arnaud Lacombe wrote:
>
>> > The idea behind this option is targeted at developers who, in the
>> > process of writing their code, want to do the occasional
>> >
>> > make W=1 [target.o]
>> >
>> > and let gcc do more extensive code checking for them. Then, they
>> > could eyeball the output for valid gcc warnings about various
>> > bugs/discrepancies which are not reported during the normal build
>> > process.
>> >
>
> [..]
>
>> > +ifeq ("$(origin W)", "command line")
>> > +  KBUILD_ENABLE_EXTRA_GCC_CHECKS = 1
>> > +  export KBUILD_ENABLE_EXTRA_GCC_CHECKS
>> > +endif
>> > +
>> You never check CC is gcc. How can you assert this ?
>
> Hmm, I somehow knew that the other compilers are going to come into the
> discussion :).
>
>> Moreover, can you certify that all the compiler supported to build
>> Linux do support the set of new warnings ?
>
> Well, as you've probably already read in the commit message, this
> option is for devs only, in case they want to do a build-check whether
> the couple of lines they just added to a .c file trigger new compiler
> warnings. So, no, I cannot certify this and I don't have to - this is
> not meant for production use anyway.
>
People _will_ end up using it in production.

>> What about icc ?
>
> I don't know, is anyone using it to build the kernel?
then what would be the point of, say `include/linux/compiler-intel.h' ?

> Even if so, icc
> might have a completely different set of -W options (totally guessing
> here) so you shouldn't use 'make W=1' with it.
>

>> old gcc?
>
> Yes, cc-option should be used in that case, I'll redo the patch.
>
>> LLVM/clang ?
>
> Can you even build the kernel with it?
>
At first sight, partly[0].

> But to make sure we're on the realistic side of things.
Whose realistic side ? yours ? If not, are you speaking for all the
Linux community ? I do not think so.

> First of all,
> the purpose of this is to quickly get gcc scream out while building your
> changes. Secondly, let's face it, the majority of developers, if not
> all, use gcc the kernel code is full of gcc-isms so accomodating all
> the compilers to such a quick-and-dirty test option is just plain too
> much.
That's a statement I would not make. Lots of compiler dependent stuff
is buried in <linux/compiler.h> for a good reason.

> Look at it this way: it is cheaper to upgrade your dev environment
> than add unnecessary and ugly code to kbuild. Even the argument with
> older gcc versions cannot weigh in enough in favor of the cc-option -
> simply upgrade your gcc.
>
Do you speak for users, in the embedded world, of BSP whose supporting
company either went defunct or is no longer maintaining the toolchain
for a dark platform, or say an architecture, in kernel, which do not
have support in mainstream binutils and support's patches are tied
with a given version of binutils/gcc ?

 - Arnaud

[0]: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/