bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils and GCC -fanalyzer


From: Paul Eggert
Subject: Re: coreutils and GCC -fanalyzer
Date: Wed, 1 Jul 2020 17:26:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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.

On 5/23/20 9:22 AM, Tim Rühsen wrote:

> This has been done for Wget2
> https://gitlab.com/gnuwget/wget2/-/blob/master/m4/wget_manywarnings.m4
>
> Example usage at L123+:
> https://gitlab.com/gnuwget/wget2/-/blob/master/configure.ac
>
> To make it usable for other projects, it needs some merging with the
> manywarnings.m4 from gnulib, IMO. I would support any volunteer as good
> as i can.

Thanks. I think this different approach should be a win. I wanted to get the old
approach working with GCC 10.1 first though (and did that via the attached
patch) before trying out this new method, so that we can verify that switching
from old to new methods improves 'configure' performance without changing the
set of flags given to GCC. Perhaps we can wait for a bit for a shakeout period
for -fanalyzer etc., and then look into switching methods.

Attachment: 0001-manywarnings-improve-port-to-GCC-10.1.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]