On Sep 25, 2014, at 12:45 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Instead of grepping, you can feed the build log to linux-log-summary. > Or when changing a driver, feed the before and after build logs to > linux-log-diff. That way you won't miss the single new warning you've > just introduced. > > https://github.com/geertu/linux-scripts Thanks for making me aware of these tools. linux-log-summary does reduce the totally insane 125,000 warnings to the merely unreasonable 10,000 or so. I'm not being sarcastic, they *are* very nice tools that I will use. Thank you for pointing me to them. I still observe that thousands of those unique warnings are emitted by the syscall table and its override initializations. I still think they should be silenced because they serve no purpose in that particular case. That is, the warning is complaining about what it is designed to complain about, but in this particular instance, the code is written as it needs to be, so why not acknowledge and capture that exception in the source? A couple thousand more come from every use of compiletime_assert, for which I do not have a solution yet. Even my macros don't help with that one. Most of the others come from null-entry table initializations, i.e. { 0 }, which give missing field initializer warnings. I'd like to define a macro something like: #define ZERO_ENTRY DIAG_PUSH DIAG_IGNORE(missing-field-initializers) \ { 0 } DIAG_POP Then simply using ZERO_ENTRY, a zero entry could be provided without a complaint from the compiler. But of course that can't be done if the DIAG_* macros aren't there. It also would keep the DIAG_* macros out of the .c files and just in the header where ZERO_ENTRY is defined. -- Mark Rustad, Networking Division, Intel Corporation
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
