From: Jeffrey Walton <noloader@gmail.com>
To: bug-gnulib@gnu.org, coreutils@gnu.org
Subject: Re: coreutils and GCC -fanalyzer
Date: Fri, 10 Jul 2020 17:37:48 -0400 [thread overview]
Message-ID: <CAH8yC8kX5jB-AV+KTwzoGfCh9eQTfgQ1zKV5-2xcBVwT7yAW6A@mail.gmail.com> (raw)
In-Reply-To: <e9385bc6-cf31-4444-d78e-013b882e8d9c@draigBrady.com>
On Fri, Jul 10, 2020 at 5:22 PM Pádraig Brady <P@draigbrady.com> wrote:
>
> On 02/07/2020 01:26, Paul Eggert wrote:
> > On 5/23/20 9:08 AM, Paul Eggert wrote:
> >
> >> So I am thinking of killing two
> >> stones by doing the following.
> >>
> >> 1. Test for -fanalyzer, -Wall, -Wextra.
> >>
> >> 2. Test for flags not automatically enabled by -fanalyzer, -Wall, -Wextra but
> >> flags that we want anyway.
> >>
> >> 3. Test for flags automatically enabled by -fanalyzer, -Wall, -Wextra that are
> >> also flags that we don't want.
> >
> > I did that in Gnulib by installing the attached patch. This could greatly
> > increase compile times due to the -fanalyzer option, so let's keep an eye out
> > for that.
>
> s/could/does/.
> compile time has gone from seconds to minutes for coreutils at least.
>
> I'd be inclined to not enable -fanalyzer by default.
> At least not until it matures more.
> -fanalyzer didn't find any actual issues in coreutils,
> and currently bails on most files (after taking lots of time about it),
> as indicated with the -Wanalyzer-too-complex option.
Just my 2 cents, but leave analyzer options to testing and QA folks.
Make the option available for convenience, but leave it off by
default.
The testers and QA folks will perform the enhanced testing on
occasion, like during a CI build or manually before a release. The
remainder of the time, regular users get a regular build.
Jeff
next prev parent reply other threads:[~2020-07-10 21:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <edfafbde-9e71-f8a9-600d-23cdfaee52a5@cs.ucla.edu>
[not found] ` <77400f8a-59ca-6d02-e5b1-e01ba0619237@draigBrady.com>
[not found] ` <a554e905-fa73-6618-90d7-ae3cb136e19d@cs.ucla.edu>
[not found] ` <e551aac0-e2fe-920a-d0ea-ca80695283d0@draigBrady.com>
[not found] ` <4aa67590-a0c3-603d-d2b1-f0751a28df29@cs.ucla.edu>
[not found] ` <3a074086-47f7-638f-50a8-cd7ceb46a11a@draigBrady.com>
2020-05-23 16:08 ` coreutils and GCC -fanalyzer Paul Eggert
2020-05-23 16:22 ` Tim Rühsen
2020-07-02 0:26 ` Paul Eggert
2020-07-10 21:21 ` Pádraig Brady
2020-07-10 21:37 ` Jeffrey Walton [this message]
2020-07-11 0:58 ` Paul Eggert
2020-07-11 14:26 ` Pádraig Brady
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH8yC8kX5jB-AV+KTwzoGfCh9eQTfgQ1zKV5-2xcBVwT7yAW6A@mail.gmail.com \
--to=noloader@gmail.com \
--cc=bug-gnulib@gnu.org \
--cc=coreutils@gnu.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).