From: Nix <nix@esperi.org.uk>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Lee Revell <rlrevell@joe-job.com>,
Jesper Juhl <jesper.juhl@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Building 100 kernels; we suck at dependencies and drown in warnings
Date: Sun, 26 Feb 2006 22:32:21 +0000 [thread overview]
Message-ID: <87fym53g5m.fsf@hades.wkstn.nix> (raw)
In-Reply-To: <20060226221401.GS27946@ftp.linux.org.uk> (Al Viro's message of "Sun, 26 Feb 2006 22:14:01 +0000")
On Sun, 26 Feb 2006, Al Viro moaned:
> On Sun, Feb 26, 2006 at 09:46:32PM +0000, Nix wrote:
>> (i.e., there's a reason that warning uses the word *might*.)
>
> The bug is in spewing tons of false positives, reducing S/N on that
> warning to nearly useless level. Note that in this case actually
> missing some would be more useful if what remains is less diluted
> by crap.
I think this might be <http://gcc.gnu.org/PR5035>.
It's in the nature of this warning that improving its accuracy is often,
to quote rth in that bug, `distinctly non-trivial'. The (numerous) new
SSA optimizers in GCC 4.1 may well have fixed it: I'd be surprised if
they hadn't zapped a heap of FPs. I doubt it'll ever improve in 4.0.x,
because the magnitude of the changes required to do so is just so large.
There is ongoing argument on the GCC list between two camps: one that
proposes moving such warnings into the frontend, and says that the
increase in FPs is worth it given the increase in warning stability (the
warnings don't go away just because you change optimization level); the
other argues against this on the basis that a warning that gives lots
of FPs is mostly useless.
Feel free to chip in the next time this argument flares up :)
--
`... follow the bouncing internment camps.' --- Peter da Silva
next prev parent reply other threads:[~2006-02-26 22:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-26 16:21 Jesper Juhl
2006-02-26 16:31 ` Jesper Juhl
2006-02-26 16:35 ` Jesper Juhl
2006-02-26 19:31 ` Dave Jones
2006-02-26 19:43 ` Jesper Juhl
2006-02-26 20:11 ` Jesper Juhl
2006-02-26 23:45 ` Nigel Cunningham
2006-02-27 2:02 ` Pavel Machek
2006-02-26 19:30 ` Dave Jones
2006-02-26 17:00 ` Adrian Bunk
2006-02-26 17:29 ` Jesper Juhl
2006-02-26 17:41 ` Adrian Bunk
2006-02-26 18:08 ` Jesper Juhl
2006-02-26 17:38 ` Jesper Juhl
2006-02-26 18:21 ` Diego Calleja
2006-02-26 18:45 ` Jesper Juhl
2006-02-26 19:03 ` Diego Calleja
2006-02-26 20:42 ` Lee Revell
2006-02-26 20:44 ` Jesper Juhl
2006-02-26 21:46 ` Nix
2006-02-26 21:49 ` Jesper Juhl
2006-02-26 21:53 ` Lee Revell
2006-02-26 21:56 ` Jesper Juhl
2006-02-26 22:08 ` Lee Revell
2006-02-26 22:12 ` Jesper Juhl
2006-02-27 17:25 ` Stephen Hemminger
2006-02-26 22:14 ` Al Viro
2006-02-26 22:32 ` Nix [this message]
2006-02-26 22:50 ` Lee Revell
2006-02-26 21:14 ` Grant Coady
2006-02-27 12:56 ` David Greaves
2006-02-28 10:30 ` Roman Zippel
2006-02-26 22:43 ` Sam Ravnborg
2006-03-02 20:25 ` Jesper Juhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fym53g5m.fsf@hades.wkstn.nix \
--to=nix@esperi.org.uk \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®