From: Finn Thain <fthain@telegraphics.com.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Landley <rob@landley.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Linux/m68k <linux-m68k@vger.kernel.org>,
Laurent Vivier <Laurent@vivier.eu>
Subject: Re: GCC?, was Re: Running m68k on qemu with external initramfs?
Date: Tue, 14 Apr 2020 09:02:45 +1000 (AEST) [thread overview]
Message-ID: <alpine.LNX.2.22.394.2004140841070.8@nippy.intranet> (raw)
In-Reply-To: <CAMuHMdXyhB52yLZ59njZ6fTZB8B1cZNWLFHcGaCxZ2TuKt7_0g@mail.gmail.com>
On Mon, 13 Apr 2020, Geert Uytterhoeven wrote:
> On Mon, Apr 13, 2020 at 11:37 AM Rob Landley <rob@landley.net> wrote:
> >
> > Did you know that if you disable optimizations you can get _more_
> > warnings?
> >
> > _disabling_ the gcse optimization triggered one of those "may be used
> > uninitialized but is a false positive 99% of the time" which in this
> > case, turned out to have a path that could trigger in a function I
> > added last week, which which was called in an else case 5 lines down.
> > (Yes, when it DIDN'T segfault, it gave me the warning.)
>
> It's indeed a pity. I looked into each and every one of them when I
> could still compile the kernel with gcc 4.1, to find the few cases that
> were real bugs...
>
It appears code generation and static analysis really are separate
problems. Code gen could be done faster when the user just wants an
executable and has no use for the analysis (up to 'git bisect'). And
static analysis works better when you have proper coverage, as you guys
have shown.
prev parent reply other threads:[~2020-04-13 23:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 0:50 Running m68k on qemu with external initramfs? Rob Landley
2020-04-11 6:12 ` Finn Thain
2020-04-12 3:36 ` Rob Landley
2020-04-12 5:29 ` Finn Thain
2020-04-12 12:34 ` Rob Landley
2020-04-12 8:27 ` John Paul Adrian Glaubitz
2020-04-12 8:31 ` Laurent Vivier
2020-04-12 21:48 ` Rob Landley
2020-04-12 23:17 ` Finn Thain
2020-04-11 12:12 ` John Paul Adrian Glaubitz
2020-04-12 12:48 ` Rob Landley
2020-04-12 13:02 ` John Paul Adrian Glaubitz
2020-04-12 21:56 ` Rob Landley
2020-04-12 23:30 ` GCC?, was " Finn Thain
2020-04-13 0:28 ` Rob Landley
2020-04-13 5:17 ` Finn Thain
2020-04-13 7:07 ` Rob Landley
2020-04-13 7:41 ` John Paul Adrian Glaubitz
2020-04-13 8:27 ` Rob Landley
2020-04-13 9:42 ` Geert Uytterhoeven
2020-04-13 23:02 ` Finn Thain [this message]
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=alpine.LNX.2.22.394.2004140841070.8@nippy.intranet \
--to=fthain@telegraphics.com.au \
--cc=Laurent@vivier.eu \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-m68k@vger.kernel.org \
--cc=rob@landley.net \
/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;
as well as URLs for NNTP newsgroup(s).