On Sep 26, 2014, at 12:58 PM,
wrote:
> On Fri, Sep 26, 2014 at 07:37:19PM +, Rustad, Mark D wrote:
>> Most of the others come from null-entry table initializations, i.e. {
>> 0 }, which give missing field initializer warnings.
>
> I'd suggest that such initializers should just be {}, not {
On Fri, Sep 26, 2014 at 07:37:19PM +, Rustad, Mark D wrote:
> Most of the others come from null-entry table initializations, i.e. {
> 0 }, which give missing field initializer warnings.
I'd suggest that such initializers should just be {}, not { 0 }, and we
should teach compilers to specifical
On Sep 25, 2014, at 12:45 AM, Geert Uytterhoeven 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.
>
> http
On Thu, Sep 25, 2014 at 09:45:29AM +0200, Geert Uytterhoeven 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.
On Tue, Sep 23, 2014 at 08:43:17PM +, Rustad, Mark D wrote:
> Well, please consider the specifics. The entire syscall table is initialized
> with a constant pattern to be sure that every item is initialized. Then each
> syscall is initialized into its proper place. The compiler is complaining t
On Mon, Sep 22, 2014 at 11:21 PM, Jeff Kirsher
wrote:
>> > Why grep through 100,000 warnings, when we should be fixing the code to
>> > prevent 100,000 warnings. Not saying that the MACRO is the best
>> > solution, it is just a solution, in hopes that it spurs discussions like
>> > this on how to
On Sep 23, 2014, at 11:44 AM, Borislav Petkov wrote:
> Again, we should take compiler warnings with a grain of salt and judge
> them only by the quality of the generated code. IMO.
The more I thought about this, the more I think it argues for having some
diagnostic control macros. Tools such as
On Sep 23, 2014, at 11:44 AM, Borislav Petkov wrote:
> On Tue, Sep 23, 2014 at 05:24:22PM +, Rustad, Mark D wrote:
>> Yes, but I think there are a few cases where it could be helpful. When
>> there is something exceptional that will throw a warning. In one of the
>> patches that Jeff sent, I
On Tue, 2014-09-23 at 20:44 +0200, Borislav Petkov wrote:
> On Tue, Sep 23, 2014 at 05:24:22PM +, Rustad, Mark D wrote:
> > Perhaps checkpatch would be a better gatekeeper for new code. OTOH,
> > some of those nested externs have already been eliminated, so at
> > least for now the warning is s
On Tue, Sep 23, 2014 at 05:24:22PM +, Rustad, Mark D wrote:
> Yes, but I think there are a few cases where it could be helpful. When
> there is something exceptional that will throw a warning. In one of the
> patches that Jeff sent, I used the DIAG_CLANG_IGNORE macro to suppress
> the warning t
On Sep 23, 2014, at 1:22 AM, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 09:50:54PM +, Rustad, Mark D wrote:
> * Fixing those is a good idea if the fixes are clean - I think we all
> agree by now that adding code just to shut up gcc is not nice.
Yes, but I think there are a few cases wh
On Sep 23, 2014, at 7:49 AM, Josh Triplett wrote:
> On Tue, Sep 23, 2014 at 10:01:20AM +0200, Borislav Petkov wrote:
>> ./arch/x86/include/asm/io_apic.h: In function ‘io_apic_modify’:
>> ./arch/x86/include/asm/io_apic.h:223:48: warning: declaration of ‘apic’
>> shadows a global declaration [-Wsh
On Tue, Sep 23, 2014 at 07:49:36AM -0700, Josh Triplett wrote:
> Here, I think the right fix involves picking a more descriptive name
> than "apic" for the global varible.
Sure, this one is simple enough and could be fixed. Something for a
newbie to tackle I'd say.
--
Regards/Gruss,
Boris.
On Tue, Sep 23, 2014 at 10:01:20AM +0200, Borislav Petkov wrote:
> ./arch/x86/include/asm/io_apic.h: In function ‘io_apic_modify’:
> ./arch/x86/include/asm/io_apic.h:223:48: warning: declaration of ‘apic’
> shadows a global declaration [-Wshadow]
> static inline void io_apic_modify(unsigned int a
On Mon, Sep 22, 2014 at 09:50:54PM +, Rustad, Mark D wrote:
> On Sep 22, 2014, at 1:33 PM, Borislav Petkov wrote:
>
> > Btw, out of curiosity, what is your use case for staring at those W=2
> > warnings?
>
> I know no one cares about out-of-tree drivers, but I have a hack that
Yah :-)
> al
On Mon, Sep 22, 2014 at 02:21:52PM -0700, Jeff Kirsher wrote:
> Nothing is wrong with grepping for an error, especially when you know
> the error your grepping for. But then again, why grep when it can be
> fixed to begin with?
Oh sure, but at what cost?
But we're on the same page here - if it c
On Sep 22, 2014, at 1:33 PM, Borislav Petkov wrote:
> Btw, out of curiosity, what is your use case for staring at those W=2
> warnings?
I know no one cares about out-of-tree drivers, but I have a hack that
allows building out-of-tree drivers without getting warnings from the
kernel includes. We
On Mon, 2014-09-22 at 22:33 +0200, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 01:09:33PM -0700, Jeff Kirsher wrote:
> > Sorry I am very frustrated at your response.
>
> You shouldn't be. Judging by your reply below it seems we do actually
> agree... mostly :-)
>
> > I am not saying that the
On Mon, Sep 22, 2014 at 01:09:33PM -0700, Jeff Kirsher wrote:
> Sorry I am very frustrated at your response.
You shouldn't be. Judging by your reply below it seems we do actually
agree... mostly :-)
> I am not saying that the proposed added MACRO is the best solution to
> this issue. Several oth
On Mon, 2014-09-22 at 21:57 +0200, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 12:44:17PM -0700, Jeff Kirsher wrote:
> > Not sure you showed us, since that is how everyone has had to do to
> > actual find W= builds useful. Just because that is how we HAVE to
> do it
> > now, does not make it
On Mon, Sep 22, 2014 at 12:44:17PM -0700, Jeff Kirsher wrote:
> Not sure you showed us, since that is how everyone has had to do to
> actual find W= builds useful. Just because that is how we HAVE to do it
> now, does not make it the best way. Here is a thought, we don't we fix
> the potential is
On Mon, 2014-09-22 at 21:21 +0200, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 06:59:23PM +, Rustad, Mark D wrote:
> > It is helpful for using the warnings to look for problems or even
> just risks.
>
> That's what W= builds are for.
>
> > Right now the number of warnings generated when
On Mon, Sep 22, 2014 at 06:59:23PM +, Rustad, Mark D wrote:
> It is helpful for using the warnings to look for problems or even just risks.
That's what W= builds are for.
> Right now the number of warnings generated when using W=2 simply tells
> people to never use W=2.
I showed you how to u
On Sep 22, 2014, at 11:40 AM, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 05:06:27PM +, Rustad, Mark D wrote:
>> Well, the whole series of patches that I made definitely went too far
>> - only the first 5 out of about 30 have been posted, but if we can
>> make some progress on generating
On Mon, Sep 22, 2014 at 05:06:27PM +, Rustad, Mark D wrote:
> The problem is that the kernel include files throw so many warnings
> that it really discourages anyone from ever going through them, even
> for a single driver. The warnings are far more valuable and usable
> when known acceptable u
On Sep 22, 2014, at 8:33 AM, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
>> The following patches silence over 100,000 warnings in a W=2
>> kernel build. This series does most of it by using the compilers
>> diagnostic controls. The first patch in the se
On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
> The following patches silence over 100,000 warnings in a W=2
> kernel build. This series does most of it by using the compilers
> diagnostic controls. The first patch in the series adds macros to
> invoke the pragmas for those controls
27 matches
Mail list logo
