qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror


From: Eric Auger
Subject: Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Date: Wed, 7 Dec 2022 21:39:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1

Hi Peter,

On 12/7/22 21:28, Peter Maydell wrote:
> On Wed, 7 Dec 2022 at 18:44, Eric Auger <eric.auger@redhat.com> wrote:
>> On 12/7/22 19:23, Richard Henderson wrote:
>>> Adding -Wall is not standard, nor all the other -W that you are
>>> adding.  I think you should not be surprised that you run into problems.
>> OK that's a useful indication. I used to have this configure cmd line
>> for a while and have not paid much attention to it until now, I
>> acknowledge. This was useful to catch compilation errors at some point I
>> guess.
>>> While you can make a case for auditing the code base and adding these
>>> to the default set of warning flags, that's a job for the next
>>> development cycle.
>> Let me clarify, I am not insisting for that fix to land in 7.2 all the
>> more so it is pretty late. I just wanted to report the compilation issue
>> and since I use the std qemu pieces with a pretty standard tool chain I
>> thought somebody else would be likely to hit the same problem.
> As Richard says, we don't expect people to randomly add extra
> warning flags, and anybody who does should expect to see extra
> warnings (and that they need to --disable-werror if they don't want
> those extra warnings to turn into errors).
>
> We specifically disable some warnings, there are some not-on-by-default
> warnings that we know we have work to do if we want to eliminate them
> (eg -Wvla) and there's probably a few where we conceptually disagree
> with a warning flag or don't find it useful for QEMU (like
> -Wgnu-statement-expression -- we deliberately use GNU statement
> expressions so warning about them isn't useful to us).
>
> Sorting through which of the currently non-enabled warning flags
> are worth trying to fix existing warnings and enable by default
> is a pretty big task (not dissimilar to sorting through Coverity
> issue reports -- maybe some of the things you fix are real bugs
> but there's a lot of false-positives to wade through to get there).
>
> maybe-uninitialized warnings are particularly awkward because whether
> you get them depends a lot on the version of the compiler and how
> smart its data analysis is.

OK. I don't exactly remember how I came to this configure cmd line.
Maybe in the old times bots were complaining about such kind of warnings
or some of the extra warning flags were used downstream. I simply
thought we had a stricter policy with regards to those and I have been
using this configure command for a long time, without trouble, until
recently, hence that belief.

Thanks

Eric
>
> thanks
> -- PMM
>




reply via email to

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