On Fri, Jul 29, 2016 at 3:19 AM, Borislav Petkov wrote:
>
> So this is exactly the problem: we should not fix perfectly fine code
> just so that gcc remains quiet. So when you say "fixed false positives"
> you actually mean, "changed it so that gcc -Wmaybe-u... doesn't fire"
>
On Fri, Jul 29, 2016 at 3:19 AM, Borislav Petkov wrote:
>
> So this is exactly the problem: we should not fix perfectly fine code
> just so that gcc remains quiet. So when you say "fixed false positives"
> you actually mean, "changed it so that gcc -Wmaybe-u... doesn't fire"
> right?
>
> And we
On Friday, July 29, 2016 12:19:32 PM CEST Borislav Petkov wrote:
> On Fri, Jul 29, 2016 at 12:08:51PM +0200, Arnd Bergmann wrote:
> > Let me try to get to the bottom of this, maybe we can get the warning
> > back in the future. It has found a number of actual bugs. The majority
> > of
On Friday, July 29, 2016 12:19:32 PM CEST Borislav Petkov wrote:
> On Fri, Jul 29, 2016 at 12:08:51PM +0200, Arnd Bergmann wrote:
> > Let me try to get to the bottom of this, maybe we can get the warning
> > back in the future. It has found a number of actual bugs. The majority
> > of
On Fri, Jul 29, 2016 at 12:08:51PM +0200, Arnd Bergmann wrote:
> Let me try to get to the bottom of this, maybe we can get the warning
> back in the future. It has found a number of actual bugs. The majority
> of -Wmaybe-uninitialized warnings that I fixed in linux-next were
> false positives
On Fri, Jul 29, 2016 at 12:08:51PM +0200, Arnd Bergmann wrote:
> Let me try to get to the bottom of this, maybe we can get the warning
> back in the future. It has found a number of actual bugs. The majority
> of -Wmaybe-uninitialized warnings that I fixed in linux-next were
> false positives
On Thursday, July 28, 2016 2:22:02 PM CEST Linus Torvalds wrote:
> On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
> wrote:
> >
> > And the new warnings were actually not so much due to new code in 4.7,
> > as the fact that in between I did a user-space upgrade,
On Thursday, July 28, 2016 2:22:02 PM CEST Linus Torvalds wrote:
> On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
> wrote:
> >
> > And the new warnings were actually not so much due to new code in 4.7,
> > as the fact that in between I did a user-space upgrade, and gcc 6.1.1
> > has regressed
On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
wrote:
>
> And the new warnings were actually not so much due to new code in 4.7,
> as the fact that in between I did a user-space upgrade, and gcc 6.1.1
> has regressed to the point of the warnings being an unusable
On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
wrote:
>
> And the new warnings were actually not so much due to new code in 4.7,
> as the fact that in between I did a user-space upgrade, and gcc 6.1.1
> has regressed to the point of the warnings being an unusable mess.
Actually, thinking more
* Linus Torvalds wrote:
> On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
> wrote:
> >
> > Once we get to the point that the warning is no longer useful, and is more
> > pain than gain, it gets disabled.
>
> Btw, I have a
* Linus Torvalds wrote:
> On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
> wrote:
> >
> > Once we get to the point that the warning is no longer useful, and is more
> > pain than gain, it gets disabled.
>
> Btw, I have a suspicion that you didn't realize that "-Wmaybe-uninitialized"
> is
On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
wrote:
>
> Once we get to the point that the warning is no longer useful, and is
> more pain than gain, it gets disabled.
Btw, I have a suspicion that you didn't realize that
"-Wmaybe-uninitialized" is separate from
On Thu, Jul 28, 2016 at 12:03 PM, Linus Torvalds
wrote:
>
> Once we get to the point that the warning is no longer useful, and is
> more pain than gain, it gets disabled.
Btw, I have a suspicion that you didn't realize that
"-Wmaybe-uninitialized" is separate from "-Wuninitialized" (which is
On Thu, Jul 28, 2016 at 1:29 AM, Ingo Molnar wrote:
>
>
> So I'm worried about this description in the changelog:
>
> | Looking at the warnings produced, every single one I looked at was a false
> | positive, and the warnings are frequent enough (and big enough) that they
> can
On Thu, Jul 28, 2016 at 1:29 AM, Ingo Molnar wrote:
>
>
> So I'm worried about this description in the changelog:
>
> | Looking at the warnings produced, every single one I looked at was a false
> | positive, and the warnings are frequent enough (and big enough) that they
> can
> | easily hide
On 2016.07.28 at 10:46 +0200, Borislav Petkov wrote:
> On Thu, Jul 28, 2016 at 10:29:15AM +0200, Ingo Molnar wrote:
> > BUT, isn't this the natural state of things, that the 'final' warnings
> > that don't get fixed are the obnoxious, false positive ones - because
> > anyone who looks at them will
On 2016.07.28 at 10:46 +0200, Borislav Petkov wrote:
> On Thu, Jul 28, 2016 at 10:29:15AM +0200, Ingo Molnar wrote:
> > BUT, isn't this the natural state of things, that the 'final' warnings
> > that don't get fixed are the obnoxious, false positive ones - because
> > anyone who looks at them will
* Ingo Molnar wrote:
> But that's my point, I believe the false positive rate is pretty low in fact,
> due
> to three factors:
>
> - 90% of the warnings get fixed by developers, we never see them upstream
>
> - I'd say a majority (say 70%) of the remaining warnings are
* Ingo Molnar wrote:
> But that's my point, I believe the false positive rate is pretty low in fact,
> due
> to three factors:
>
> - 90% of the warnings get fixed by developers, we never see them upstream
>
> - I'd say a majority (say 70%) of the remaining warnings are flagging
>
Firstly, I'd like to stress it that I know that the commit is upstream and
there's
a less than 1% chance for it to be reverted. I'm not arguing with the
expectation
to see it reverted, I'm arguing because I'm not convinced about the underlying
technical arguments.
Secondly, I'd like to
Firstly, I'd like to stress it that I know that the commit is upstream and
there's
a less than 1% chance for it to be reverted. I'm not arguing with the
expectation
to see it reverted, I'm arguing because I'm not convinced about the underlying
technical arguments.
Secondly, I'd like to
On Thu, Jul 28, 2016 at 10:29:15AM +0200, Ingo Molnar wrote:
> BUT, isn't this the natural state of things, that the 'final' warnings
> that don't get fixed are the obnoxious, false positive ones - because
> anyone who looks at them will say "oh crap, idiotic compiler!"?
Hmm, so my experience is
On Thu, Jul 28, 2016 at 10:29:15AM +0200, Ingo Molnar wrote:
> BUT, isn't this the natural state of things, that the 'final' warnings
> that don't get fixed are the obnoxious, false positive ones - because
> anyone who looks at them will say "oh crap, idiotic compiler!"?
Hmm, so my experience is
* Borislav Petkov wrote:
> Hi Linus,
>
> about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):
>
> Good! Finally!
>
> This thing was really getting on my nerves.
So I'm worried about this description in the changelog:
| Looking at the warnings produced,
* Borislav Petkov wrote:
> Hi Linus,
>
> about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):
>
> Good! Finally!
>
> This thing was really getting on my nerves.
So I'm worried about this description in the changelog:
| Looking at the warnings produced, every single one I
..@suse.de>
> Subject: [PATCH -v2] Kbuild: Move -Wmaybe-uninitialized to W=1
>
> This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
> also says that gcc cannot always know whether the warning is issued
> correctly:
>
> "These warnings are made op
, 2014 at 12:53:39PM +0200, Borislav Petkov wrote:
> Ok, here's a v2 which goes ontop of
>
> http://lkml.kernel.org/r/1404175346-12330-1-git-send-email-beh...@converseincode.com
>
> After this, all warnings stuff should be back to normal.
>
> ---
> From: Borislav Petkov
On Thu, 2014-07-10 at 12:42 +0200, Borislav Petkov wrote:
> I haven't even wished for it but just to prove everybody my point: just
> built rc4+ from Linus' repo with gcc 4.9.0, see below.
>
> Now all of a sudden there's more noise, maybe because this is a
> different .config. However, I doubt
And,
I haven't even wished for it but just to prove everybody my point: just
built rc4+ from Linus' repo with gcc 4.9.0, see below.
Now all of a sudden there's more noise, maybe because this is a
different .config. However, I doubt those are real bugs.
A cursory look through those shows that
And,
I haven't even wished for it but just to prove everybody my point: just
built rc4+ from Linus' repo with gcc 4.9.0, see below.
Now all of a sudden there's more noise, maybe because this is a
different .config. However, I doubt those are real bugs.
A cursory look through those shows that
On Thu, 2014-07-10 at 12:42 +0200, Borislav Petkov wrote:
I haven't even wished for it but just to prove everybody my point: just
built rc4+ from Linus' repo with gcc 4.9.0, see below.
Now all of a sudden there's more noise, maybe because this is a
different .config. However, I doubt those
On Tue, Jul 08, 2014 at 11:25:20AM +0200, Paul Bolle wrote:
> Is the fact that this generates false positives by itself enough to
> downgrade this check to W=1?
>
> I do not have any hard numbers to back up my claims, but I'd like to
> point out that it is possible that we never see many of the
On Mon, 2014-07-07 at 12:53 +0200, Borislav Petkov wrote:
> This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
> also says that gcc cannot always know whether the warning is issued
> correctly:
>
> "These warnings are made optional because GCC is not smart enough to see
> all
On Mon, 2014-07-07 at 12:53 +0200, Borislav Petkov wrote:
This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
also says that gcc cannot always know whether the warning is issued
correctly:
These warnings are made optional because GCC is not smart enough to see
all the
On Tue, Jul 08, 2014 at 11:25:20AM +0200, Paul Bolle wrote:
Is the fact that this generates false positives by itself enough to
downgrade this check to W=1?
I do not have any hard numbers to back up my claims, but I'd like to
point out that it is possible that we never see many of the
Ok, here's a v2 which goes ontop of
http://lkml.kernel.org/r/1404175346-12330-1-git-send-email-beh...@converseincode.com
After this, all warnings stuff should be back to normal.
---
From: Borislav Petkov
Subject: [PATCH -v2] Kbuild: Move -Wmaybe-uninitialized to W=1
This warning is enabled
Ok, here's a v2 which goes ontop of
http://lkml.kernel.org/r/1404175346-12330-1-git-send-email-beh...@converseincode.com
After this, all warnings stuff should be back to normal.
---
From: Borislav Petkov b...@suse.de
Subject: [PATCH -v2] Kbuild: Move -Wmaybe-uninitialized to W=1
This warning
CFLAGS because it is not necessary - apparently the following
-Wmaybe-uninitialized reenables it again).
---
From: Borislav Petkov
Subject: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1
This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
also says that gcc cannot always know w
it is not necessary - apparently the following
-Wmaybe-uninitialized reenables it again).
---
From: Borislav Petkov b...@suse.de
Subject: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1
This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
also says that gcc cannot always know
40 matches
Mail list logo