On Wed, 10 Jul 2013, Manuel López-Ibáñez wrote:
>> This points to other ideas:
>> 1) how about adding a helper switch to show what is included in Wall?
>> such as -Wall-print
>
> Doesn't
>
> gcc -Q -Wall --help=warnings
>
> give you this?
Yes, but...how would I know to use this?
For example, g
On Wed, Jul 10, 2013 at 06:11:11PM +0200, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
Not always. Any project large enough (or serious
Hi,
On Thu, 11 Jul 2013, Gabriel Dos Reis wrote:
> > Arg, no. -Werror is very useful for development and I'm sure that
> > code quality increases because of it, but it should never be enabled
> > by default for releases. I think about 80% of the bugs we've had
> > filed so far for packages f
On Thu, Jul 11, 2013 at 11:11:28AM +0200, Andreas Arnez wrote:
> > On 07/10/2013 04:51 AM, Andreas Arnez wrote:
> >> OK, I may be biased, because I have *only* seen false positives with
> >> this warning so far. Others may have made better experience with it.
> > It's found numerous bugs across ma
Jeff Law writes:
> On 07/10/2013 04:51 AM, Andreas Arnez wrote:
>> OK, I may be biased, because I have *only* seen false positives with
>> this warning so far. Others may have made better experience with it.
> It's found numerous bugs across many projects. The reduction in bug
> reports against
On Thu, Jul 11, 2013 at 12:42 AM, Ryan Hill wrote:
> On Wed, 10 Jul 2013 07:49:18 -0500
> Gabriel Dos Reis wrote:
>
>> If we include a warning in -Wall then it is because we believe it to be
>> generally useful and likely to uncover common bugs/mistakes. It is therefore
>> reasonable for users t
On Wed, 10 Jul 2013 07:49:18 -0500
Gabriel Dos Reis wrote:
> If we include a warning in -Wall then it is because we believe it to be
> generally useful and likely to uncover common bugs/mistakes. It is therefore
> reasonable for users to issue -Wall -Werror even in application delivery mode.
Ar
On Wed, Jul 10, 2013 at 4:37 PM, Manuel López-Ibáñez
wrote:
> To be honest, I agree with Gabriel here. And I would go a step
> forward, I would say that we are too timid with the warnings we enable
> by default or by -Wall. We should warn more agressively, and let users
> disable the warnings tha
On Wed, Jul 10, 2013 at 2:37 PM, Manuel López-Ibáñez
wrote:
>> This points to other ideas:
>> 1) how about adding a helper switch to show what is included in Wall?
>> such as -Wall-print
>
> Doesn't
>
> gcc -Q -Wall --help=warnings
>
> give you this?
>
Yes it does work as expected.
> Otherwise,
> This points to other ideas:
> 1) how about adding a helper switch to show what is included in Wall?
> such as -Wall-print
Doesn't
gcc -Q -Wall --help=warnings
give you this?
Otherwise, I think it is a bug.
> 2) how about making -Wall configurable -- a default config file is
> looked at by th
On Wed, Jul 10, 2013 at 1:20 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote:
>> There are two fundamental problems:
>> 1) uninit warning has false positives.
>> 2) people disagree what is the expected behavior of -Wall.
>>
>> 1) can only be solved by improv
On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote:
> There are two fundamental problems:
> 1) uninit warning has false positives.
> 2) people disagree what is the expected behavior of -Wall.
>
> 1) can only be solved by improving the analysis.
I think we should focus on this. While we can
Xinliang David Li writes:
> What about introducing a new blanket warning kind that excludes
> anything with false positives? something like -WALL ?
This still doesn't help if any new compiler version
could ever add a new warning.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
There are two fundamental problems:
1) uninit warning has false positives.
2) people disagree what is the expected behavior of -Wall.
1) can only be solved by improving the analysis. The new option is a
reasonable way to solve 2), unless you think the only way to solve it
is to change the behavio
On Wed, Jul 10, 2013 at 2:27 PM, Xinliang David Li wrote:
> On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis
> wrote:
>> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li
>> wrote:
>>> What about introducing a new blanket warning kind that excludes
>>> anything with false positives? somethin
On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote:
>> What about introducing a new blanket warning kind that excludes
>> anything with false positives? something like -WALL ?
>
> I am doubtful "more ropes" is the answer.
>
Reason
On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote:
> What about introducing a new blanket warning kind that excludes
> anything with false positives? something like -WALL ?
I am doubtful "more ropes" is the answer.
-- Gaby
What about introducing a new blanket warning kind that excludes
anything with false positives? something like -WALL ?
David
On Wed, Jul 10, 2013 at 3:51 AM, Andreas Arnez wrote:
> Jeff Law writes:
>
>> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>>> Andrew Haley writes:
>>>
On 07/09/2013
On 07/10/2013 05:48 PM, paul_kon...@dell.com wrote:
> It seems to me there are two cases. One is releases, where you want to
> maximize the odds that an install will work. For that you clearly don't want
> -Werror, and you might want to trim back the warnings. The other is the
> development p
On Jul 10, 2013, at 12:44 PM, Jeff Law wrote:
> On 07/10/2013 10:29 AM, Jonathan Wakely wrote:
>> On 10 July 2013 17:11, Andi Kleen wrote:
>>> FWIW basically -Werror -Wall defines a compiler version specific
>>> variant of C. May be great for individual developers, but it's always
>>> a serious m
On 07/10/2013 10:29 AM, Jonathan Wakely wrote:
On 10 July 2013 17:11, Andi Kleen wrote:
FWIW basically -Werror -Wall defines a compiler version specific
variant of C. May be great for individual developers, but it's always
a serious mistake in any distributed Makefile.
That's a very nice way t
On Wed, Jul 10, 2013 at 07:42:55AM -0700, Andi Kleen wrote:
> Andrew Haley writes:
>
> > On 07/09/2013 12:59 PM, Andreas Arnez wrote:
> >> With this situation at hand, I wonder whether it's a good idea to keep
> >> maybe-uninitialized included in -Wall. Projects which have been using
> >> "-Wall
On 10 July 2013 17:11, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
That's a very nice way to put it.
On 07/10/2013 05:11 PM, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
I could not have put it any better.
Andrew.
> No. People expect that -Werror turns warnings into errors.
> That is what we have documented for years.
> Starting to special case these things is a royal road to confusion,
> and a slippery slope.
Ok, I will keep removing -Werrors from Makefiles then.
FWIW basically -Werror -Wall defines a co
On Wed, Jul 10, 2013 at 9:42 AM, Andi Kleen wrote:
> Andrew Haley writes:
>
>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>> With this situation at hand, I wonder whether it's a good idea to keep
>>> maybe-uninitialized included in -Wall. Projects which have been using
>>> "-Wall -Werror" suc
On 07/10/2013 04:51 AM, Andreas Arnez wrote:
Jeff Law writes:
OK, I may be biased, because I have *only* seen false positives with
this warning so far. Others may have made better experience with it.
It's found numerous bugs across many projects. The reduction in bug
reports against GCC whic
On Jul 10, 2013, at 10:42 AM, Andi Kleen wrote:
> Andrew Haley writes:
>
>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>> With this situation at hand, I wonder whether it's a good idea to keep
>>> maybe-uninitialized included in -Wall. Projects which have been using
>>> "-Wall -Werror" succ
Andrew Haley writes:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced to
>> investigate n
On Tue, Jul 9, 2013 at 4:57 PM, Jeff Law wrote:
> I personally like -Wall -Werror. While we do run into false positives and
> the set of false positives does change from release to release as a result
> of optimizations, I believe there's been an overall improvement in the
> quality of the codeb
Tom Tromey writes:
> gdb only enables it for the development branch, not for releases. If
> you're building from CVS you're expected to know how to either fix
> these problems or disable -Werror. Typically the fix is trivial; if
> you look through the archives you'll see fixes along these lines
Jeff Law writes:
> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>> Andrew Haley writes:
>>
>>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
With this situation at hand, I wonder whether it's a good idea to keep
maybe-uninitialized included in -Wall. Projects which have been using
On 07/09/2013 07:56 AM, Andreas Arnez wrote:
Andrew Haley writes:
On 07/09/2013 12:59 PM, Andreas Arnez wrote:
With this situation at hand, I wonder whether it's a good idea to keep
maybe-uninitialized included in -Wall. Projects which have been using
"-Wall -Werror" successfully for many ye
Andrew> I would question the appropriateness of using -Wall -Werror in
Andrew> production code.
Andreas> What matters is whether *some* stages of production code
Andreas> development use this combination of options. It could
Andreas> certainly be argued whether it should also be a project's
Andre
Andrew Haley writes:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced to
>> investigate n
On 07/09/2013 02:56 PM, Andreas Arnez wrote:
> What matters is whether *some* stages of production code development use
> this combination of options. It could certainly be argued whether it
> should also be a project's "configure" default, like currently the case
> for gdb.
It's not a problem fo
On 9 July 2013 13:04, Andrew Haley wrote:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced
On 07/09/2013 12:59 PM, Andreas Arnez wrote:
> With this situation at hand, I wonder whether it's a good idea to keep
> maybe-uninitialized included in -Wall. Projects which have been using
> "-Wall -Werror" successfully for many years are now forced to
> investigate non-existing bugs in their cod
When building gdb with newer gcc versions I frequently stumble across
maybe-uninitialized false positives, like the ones documented in bug
57237. Various bugs address similar issues, and in bug 56526 Jakub
Jelinek wrote:
> Maybe-uninitialized warnings have tons of known false positives, while
> t
39 matches
Mail list logo
