Re: RFC: -Wall by default

Re: RFC: -Wall by default

[Dominique Dhumieres]

> >> We do have regular requests for this, so it is not just out of thin
> >> air.
> >
> > Perhaps, but I think that changing the default like this is far too
> > invasive.  ?GCC should do what it's told, if a user asks for warnings,
> > give them, if they don't, then don't.
> 
> It is hard to define "what it is told" means -- we are already in gray
> zone.
> 
> > I suspect changing the default like this will generate a flood of
> > complaints.
> 
> Really?  Such as what?

At least me!-(how many "regular requests" compared to the number of gcc
users?).

> If we get floods of complaints, that can only that -Wall too many
> false positives;
> but I don't think it does.  We have been careful over the years to
> watch for that effect.

[macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.c | wc -l
    1060
[macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.h | wc -l
      21

Doesn't that count as "false positives"? While -Wunused can help to spot 
some "copy&paste" errors, most of the time the warning just reflects some 
harmless sloppyness.

IMO only the warnings in C that are likely errors should be the default as 
it is in gfortran (don't ask for examples of such warnings for C, I am 
quasi-illiterate).


Dominique

PS -Wall is a simple enough option to be remembered by all users who need 
it (if they don't use it, they don't want it).

Re: RFC: -Wall by default

[Robert Dewar]

On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:

> IMO only the warnings in C that are likely errors should be the default as
> it is in gfortran (don't ask for examples of such warnings for C, I am
> quasi-illiterate).

That's also the default philosophy in GNAT, there never should be false
positives at all in the default mode IMO (well hardly ever :-)
>
>
> Dominique
>
> PS -Wall is a simple enough option to be remembered by all users who need
> it (if they don't use it, they don't want it).

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 1:34 PM, Dominique Dhumieres <dominiq@lps.ens.fr> wrote:
>> >> We do have regular requests for this, so it is not just out of thin
>> >> air.
>> >
>> > Perhaps, but I think that changing the default like this is far too
>> > invasive.  ?GCC should do what it's told, if a user asks for warnings,
>> > give them, if they don't, then don't.
>>
>> It is hard to define "what it is told" means -- we are already in gray
>> zone.
>>
>> > I suspect changing the default like this will generate a flood of
>> > complaints.
>>
>> Really?  Such as what?
>
> At least me!-(how many "regular requests" compared to the number of gcc
> users?).

well, you can have a look at our bugzilla database, and look for -Wall
for example
and follow the discussions there.

>> If we get floods of complaints, that can only that -Wall too many
>> false positives;
>> but I don't think it does.  We have been careful over the years to
>> watch for that effect.
>
> [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.c | wc -l
>    1060
> [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.h | wc -l
>      21
>
> Doesn't that count as "false positives"?

I said "too many false positive".  I did not say "no false positive".
What you would be more informative is the ratio of functions
with that attribute over the number of function definitions.


> IMO only the warnings in C that are likely errors should be the default as

I can leave with that.  However, here is the thing: We put in -Wall the warnings
that are likely errors.  I suspect if we find something in -Wall that
are not likely
errors, then that is an engineering bug from our part and we should fix it.

> it is in gfortran (don't ask for examples of such warnings for C, I am
> quasi-illiterate).
>
>
> Dominique
>
> PS -Wall is a simple enough option to be remembered by all users who need
> it (if they don't use it, they don't want it).

The trouble is that most users find it an annoyance and don't
remember.  And they
ask: if it is so simple, why isn't it included by default?

This particular request came out of long discussions with people frustrated
by the way GCC behaves compared to competitors.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:
>
>> IMO only the warnings in C that are likely errors should be the default as
>> it is in gfortran (don't ask for examples of such warnings for C, I am
>> quasi-illiterate).
>
>
> That's also the default philosophy in GNAT,

In which case you should NOT be objecting to the proposal :-)

>  there never should be false
> positives at all in the default mode IMO (well hardly ever :-)
>
>>
>>
>> Dominique
>>
>> PS -Wall is a simple enough option to be remembered by all users who need
>> it (if they don't use it, they don't want it).
>
>

Re: RFC: -Wall by default

[Eric Botcazou]

> The trouble is that most users find it an annoyance and don't
> remember.  And they ask: if it is so simple, why isn't it included by
> default? 

Huh?  -Wall is supposed to be simple to remember, but its implementation and 
effects are of course not simple at all.

-- 
Eric Botcazou

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 5:56 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> The trouble is that most users find it an annoyance and don't
>> remember.  And they ask: if it is so simple, why isn't it included by
>> default?
>
> Huh?  -Wall is supposed to be simple to remember, but its implementation and
> effects are of course not simple at all.

From developer perspective, we think that -Wall is so simple to
remember, because
in fact, we are used to handle so many complex things that this one five letter
is nothing.  However, users aren't as sophisticated as we would like them to
(I am not being condescending.)  The way we have to approach this is how can
we satisfy persistent demands and still remain competitive.

Again, this proposal does not come out of a whim.

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:

> Again, this proposal does not come out of a whim.

But it does seem to come out of a few anecdotal requests
for a change, and you always have to be careful in considering
such input, because of course people who agree with the status
quo do not write in complaining. I see no evidence that a
majority of users are in favor of this change.

By the way, to me a much more significant issue is the default
optimization level. Gcc code quality is plain horrible at -O0,
often MUCH worse that competitive compilers with default
optimization (most compilers do much more than -O0 by default).

We have run into people running benchmarks where they were
specifically prohibited from using other than the default
options, and gcc fared badly in such comparisons.

So we have wondered from time to time whether -O1 should
be the default, but the debugger is not well behaved at
-O1, and it's too much of a change I am afraid.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/4/2012 6:42 PM, Gabriel Dos Reis wrote:
> On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:
>>
>>> IMO only the warnings in C that are likely errors should be the default as
>>> it is in gfortran (don't ask for examples of such warnings for C, I am
>>> quasi-illiterate).
>>
>>
>> That's also the default philosophy in GNAT,
>
> In which case you should NOT be objecting to the proposal :-)

-Wall is roughtly equivalent to -gnatwa in the GNAT front end,
and this is definitely NOT on by default. If you run GNAT in
default mode, there are virtually no false positives, since
the only warnings on by default are the kind of warnings that
say "if you execute this statement, your program will go wrong"
>
>>   there never should be false
>> positives at all in the default mode IMO (well hardly ever :-)
>>
>>>
>>>
>>> Dominique
>>>
>>> PS -Wall is a simple enough option to be remembered by all users who need
>>> it (if they don't use it, they don't want it).
>>
>>

Re: RFC: -Wall by default

[Miles Bader]

dominiq@lps.ens.fr (Dominique Dhumieres) writes:
> PS -Wall is a simple enough option to be remembered by all users who
> need it

As is -Wno-all, of course.

> (if they don't use it, they don't want it).

That isn't necessarily the case.

In my experience, there seem to be a lot of developers who simply
don't think much about the issue to the point of adding warning
options, but who are not really averse to _heeding_ warnings that the
compiler emits by default.

It's kind of hard to say where the right balance lies given gcc's
disparate user community, but ... one way to find out is try... :]

For instance, how about adding -Wall to the default options now, and
then re-evaluate the issue based on any complaints that come in from
people using snapshots?  That's hardly a perfect method, as the sort
of people who run compiler snapshots are maybe not entirely
representative, but at least it's better data than one gets by simply
sitting around and pontificating...

-Miles

-- 
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.

Re: RFC: -Wall by default

[Miles Bader]

Robert Dewar <dewar@adacore.com> writes:
> We have run into people running benchmarks where they were
> specifically prohibited from using other than the default
> options, and gcc fared badly in such comparisons.

Yeah, there was the silly "benchmark" at phoronix where they came to
the conclusion that tcc was a better compiler than gcc because it
generated faster programs when run without any options...

[*] Phoronix is well known for completely clueless benchmarking
practices, but ... unfortunately some people actually seem to pay
attention to what they say.

-miles

-- 
Innards, n. pl. The stomach, heart, soul, and other bowels.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
>
>> Again, this proposal does not come out of a whim.
>
>
> But it does seem to come out of a few anecdotal requests
> for a change,

It does appear very disturbing that you would dismiss repeated
requests on the basis that they are anecdotal without offering
evidence.  What is more, we seem to have implemented a feature
that makes it even more intimidating for potential users to fill
out such requests.

> and you always have to be careful in considering
> such input, because of course people who agree with the status
> quo do not write in complaining.

I do see evidence to the contrary to that claim, starting with this
very thread AND the bugzilla database that we seem to have
designed to intimidate future requesters.

> I see no evidence that a
> majority of users are in favor of this change.

This strikes me as a way to a self-fullfilling prophecy.

> By the way, to me a much more significant issue is the default
> optimization level. Gcc code quality is plain horrible at -O0,
> often MUCH worse that competitive compilers with default
> optimization (most compilers do much more than -O0 by default).

One cannot seriously argue for "do what it is told" and at the
same time complain about default level of optimization :-)  Furthermore,
the problem you see with the default level of optimization is not in
conflict with default level of diagnostics.  I am approaching the issue
from the point of view of diagnostics maintainer; if you want to raise
the default level of optimization you should feel free to make a proposal.

> We have run into people running benchmarks where they were
> specifically prohibited from using other than the default
> options, and gcc fared badly in such comparisons.

That is no argument against diagnostic level by default. In fact, it
appears to support the claim that many users run the compiler
without options -- and the argument of -Wall being short to remember
is evenless potent since -O is even shorter to remember.


>
> So we have wondered from time to time whether -O1 should
> be the default, but the debugger is not well behaved at
> -O1, and it's too much of a change I am afraid.

Again, that isn't an argument against more useful diagnostic level by default.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 8:27 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/4/2012 6:42 PM, Gabriel Dos Reis wrote:
>>
>> On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>>
>>> On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:
>>>
>>>> IMO only the warnings in C that are likely errors should be the default
>>>> as
>>>> it is in gfortran (don't ask for examples of such warnings for C, I am
>>>> quasi-illiterate).
>>>
>>>
>>>
>>> That's also the default philosophy in GNAT,
>>
>>
>> In which case you should NOT be objecting to the proposal :-)
>
>
> -Wall is roughtly equivalent to -gnatwa in the GNAT front end,
> and this is definitely NOT on by default. If you run GNAT in
> default mode, there are virtually no false positives, since
> the only warnings on by default are the kind of warnings that
> say "if you execute this statement, your program will go wrong"

like calling a function with non-void return type whose definition
ails to return value.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 11:11 PM, Miles Bader <miles@gnu.org> wrote:

> For instance, how about adding -Wall to the default options now, and
> then re-evaluate the issue based on any complaints that come in from
> people using snapshots?

I believe this would offer far more evidence for/against the notion
of the change being bold and/or inconvenient to users.

-- Gaby

Re: RFC: -Wall by default

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> For instance, how about adding -Wall to the default options now, and
> then re-evaluate the issue based on any complaints that come in from
> people using snapshots?  That's hardly a perfect method, as the sort
> of people who run compiler snapshots are maybe not entirely
> representative, but at least it's better data than one gets by simply
> sitting around and pontificating...

I guess it's pretty obvious, but I meant to say "... and then
later re-evaluate the issue before the next release ...".

-miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: RFC: -Wall by default

[Arnaud Charlet]

Can someone summarize what the most useful warnings people are expecting
that -Wall would bring?

I suspect not all of -Wall would actually be welcome/a good idea by default,
and we might be looking for a better compromise where most warnings are
enabled by default, but not "all".

In particular, I'm not convinced that -Wuninitialized should be enabled
by default, precisely because this warning does generate a good bunch
of false positives.

So to me it's not black or white, and considering -Wall as a single entity
is not the right way to address these user complains IMO.

Arno

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar <dewar@adacore.com> wrote:
>> On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
>>
>>> Again, this proposal does not come out of a whim.
>>
>>
>> But it does seem to come out of a few anecdotal requests
>> for a change,
>
> It does appear very disturbing that you would dismiss repeated
> requests on the basis that they are anecdotal without offering
> evidence.  What is more, we seem to have implemented a feature
> that makes it even more intimidating for potential users to fill
> out such requests.

Well, fact is that we of course do not get any requests reading
"Please keep -Wall not enabled by default".  I think if we would
they would outnumber the requests for the opposite.

Richard.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:36 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar <dewar@adacore.com> wrote:
>>> On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
>>>
>>>> Again, this proposal does not come out of a whim.
>>>
>>>
>>> But it does seem to come out of a few anecdotal requests
>>> for a change,
>>
>> It does appear very disturbing that you would dismiss repeated
>> requests on the basis that they are anecdotal without offering
>> evidence.  What is more, we seem to have implemented a feature
>> that makes it even more intimidating for potential users to fill
>> out such requests.
>
> Well, fact is that we of course do not get any requests reading
> "Please keep -Wall not enabled by default".

If you try to submit a request about -Wall, you get a real time search
that shows related requests and how they had been dismissed
(in my opinion too summarily).  That has a dissuading effect to filing
another request of the same type.  So, you might come to the conclusion
you do not get enough, but because you have a system in place to dissuade
such request.  It is a system for self-fulfulling prophecy.

> I think if we would
> they would outnumber the requests for the opposite.

I don't know about that :-)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 12:17 AM, Miles Bader wrote:
> Robert Dewar<dewar@adacore.com>  writes:
>> We have run into people running benchmarks where they were
>> specifically prohibited from using other than the default
>> options, and gcc fared badly in such comparisons.
>
> Yeah, there was the silly "benchmark" at phoronix where they came to
> the conclusion that tcc was a better compiler than gcc because it
> generated faster programs when run without any options...
>
> [*] Phoronix is well known for completely clueless benchmarking
> practices, but ... unfortunately some people actually seem to pay
> attention to what they say.

Well a lot of users have been burned by using optimization
options, either becausae of compiler bugs, or because of bugs
in their own code triggered by optimization. So the requirement
of not using any optimization options is not that uncommon.
>
> -miles
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 12:23 AM, Gabriel Dos Reis wrote:

>> -Wall is roughtly equivalent to -gnatwa in the GNAT front end,
>> and this is definitely NOT on by default. If you run GNAT in
>> default mode, there are virtually no false positives, since
>> the only warnings on by default are the kind of warnings that
>> say "if you execute this statement, your program will go wrong"
>
> like calling a function with non-void return type whose definition
> ails to return value.

Right, BTW in Ada a failure to provide a return value is detected at
run time and raises Program_Error. This is a clear case where a
warning is always desirable (basically this would be an error in
the language, except that to make it an error would require going
into the whole issue of defining possible threads of control, and
that's too much formal effort for too little gain at the level of
the language standard. So in GNAT, this is a warning that is on
by default. Like all warnings it can be suppressed, either by
suppressing all warnings (-gnatws) or by providing a Warnings
Off pragma that suppresses this particular warning.

Note that the ONE and only case where this warning is a false
positive is the ACATS test that makes sure you raise an
exception (in practice we suppress all warnings for ACATS
tests anyway, since they are deliberately full of dubious
coding practices!)

I wonder if there is a better forum for discussing whether
-Wall should be the default than this one. After all we always
emphasize that this list is for gcc developers, and this
particular issue is one better discussed by gcc users. Yes
I know there are gcc users on this list too (I am one!) but
still we don't exactly get representative user input on this
list!

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 2:39 AM, Arnaud Charlet wrote:
> Can someone summarize what the most useful warnings people are expecting
> that -Wall would bring?
>
> I suspect not all of -Wall would actually be welcome/a good idea by default,
> and we might be looking for a better compromise where most warnings are
> enabled by default, but not "all".
>
> In particular, I'm not convinced that -Wuninitialized should be enabled
> by default, precisely because this warning does generate a good bunch
> of false positives.
>
> So to me it's not black or white, and considering -Wall as a single entity
> is not the right way to address these user complains IMO.

This seems a good direction for the discussion to me, the issue
in practice revolves around

a) false positives

b) warnings that are not false positives, but that are
incomprehensible to nonexpert users

A set of warnings that for the most part avoids these two
problems is precisely what can be reasonably on by default.

There is a third category

c) warnings about things that are not errors but seem like
sloppy or unnecessary code (e.g. unused variables).

Category c) is trickier.

Generally the philosophy in GNAT is to enable by default
all warnings that avoid a) b) or c) and correspond to
definite likely errors.
>
> Arno

Re: RFC: -Wall by default

[Eric Botcazou]

> From developer perspective, we think that -Wall is so simple to
> remember, because
> in fact, we are used to handle so many complex things that this one five
> letter is nothing.  However, users aren't as sophisticated as we would like
> them to (I am not being condescending.)  The way we have to approach this
> is how can we satisfy persistent demands and still remain competitive.

I personally don't buy the "can't remember" argument.  When you use GCC, you 
just have to remember -g, -O, -W and that's pretty much it.

-- 
Eric Botcazou

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
> Well a lot of users have been burned by using optimization
> options, either becausae of compiler bugs, or because of bugs
> in their own code triggered by optimization. So the requirement
> of not using any optimization options is not that uncommon.

But no-optimizations (-O0) should not necessarily be the default
for these reasons.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:42:02 -0400, Robert Dewar wrote:
> c) warnings about things that are not errors but seem like
> sloppy or unnecessary code (e.g. unused variables).

This is sometimes an error, e.g. a variable name is used in the code
instead another one (but of course, such warnings won't be able to
detect all similar errors).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
> On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
>> Well a lot of users have been burned by using optimization
>> options, either becausae of compiler bugs, or because of bugs
>> in their own code triggered by optimization. So the requirement
>> of not using any optimization options is not that uncommon.
>
> But no-optimizations (-O0) should not necessarily be the default
> for these reasons.

I think it is a problem that even at -O1 the debugger is
seriously limited, especially for an inexperienced user.

What is missing to me is a reasonable cleanup of the code that
would remove some of the junk at -O0 but not impact debugging.
In fact a reasonable criterion would be all the optimization
that is cheap to do and does not affect debugging.

Then I would make THAT the default (or simply redefine -O0
to be this level, I see no real advantage in -O0 as it is now)

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 02:45 PM, Eric Botcazou wrote:
> I personally don't buy the "can't remember" argument. When you use 
> GCC, you just have to remember -g, -O, -W and that's pretty much it. 


It is not that they can't remember. I am a TA at a moderately basic 
programming course,
and student submit home assignments with horrible errors. These errors, 
such as
free(*str) or *str=malloc(n)  are easily be caught by -Wall. I have to 
remember to
advise them to use -Wall and to fix all the warnings, which I sometimes 
forget to do.

Many of the students don't know of -Wall because they don't read the gcc 
manual,
either because they are overwhelmed with assignments and exams, or because
they are intimidated by big manuals written in technical English. Either 
way, many
won't use -Wall unless they are told to.

My conclusion: it would be much better for beginners to have more 
warnings turned on.

<rant>
As for specific warnings, I hate that the the code (a&&b || c&&d), which 
did not cause a
warning on older gcc version now gives a warning. I would not want it on 
by default since
it forces users to write too many parentheses in ((a&&b)||(c&&d)) which 
makes the expression
less readable. What next? Warn about (a*b+c*d) ? I would hate to write 
((a*b)+(c*d)).

Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less clear 
and deserves a warning,
but: & vs. | ; && vs. || ; are at least as common as * vs. + that 
programmers ought to know
them.
</rant>

Michael

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 08:17:57 -0400, Robert Dewar wrote:
> On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
> >But no-optimizations (-O0) should not necessarily be the default
> >for these reasons.
> 
> I think it is a problem that even at -O1 the debugger is
> seriously limited, especially for an inexperienced user.

OK.

Now, AFAIK, compiling and running programs occurs much more often
than debugging them. So, I would say that -O1 should be the default.
The user can still recompile his program with -O0 (or future better
option) if he needs to run the debugger on it; if he doesn't know
that, there should be some feature in the debugger to tell the user
what to do.

> What is missing to me is a reasonable cleanup of the code that
> would remove some of the junk at -O0 but not impact debugging.
> In fact a reasonable criterion would be all the optimization
> that is cheap to do and does not affect debugging.

I think that for debugging, there should be a single option to
disable optimizations that are unsafe for the debugger and that
would add debugging information (such as what -g does). In short,
the user would just have to add this option, which should do all
the magic for debugging.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:28 AM, Michael Veksler wrote:

> It is not that they can't remember. I am a TA at a moderately basic
> programming course,
> and student submit home assignments with horrible errors. These errors,
> such as
> free(*str) or *str=malloc(n)  are easily be caught by -Wall. I have to
> remember to
> advise them to use -Wall and to fix all the warnings, which I sometimes
> forget to do.

Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need? Indeed for such a course wouldn't it
be better to use an appropriate IDE, so they could concentrate on the
task at hand and not fiddling with commands. Yes, I think it is very
important for students to learn what is going on, but you can't do
everything at once in a basic course.

And even in the context you give, surely it is not too much to expect
a TA to remember important advice like this?

Re: RFC: -Wall by default

[Andrey Belevantsev]

On 05.04.2012 16:33, Robert Dewar wrote:
> On 4/5/2012 8:28 AM, Michael Veksler wrote:
>
>> It is not that they can't remember. I am a TA at a moderately basic
>> programming course,
>> and student submit home assignments with horrible errors. These errors,
>> such as
>> free(*str) or *str=malloc(n) are easily be caught by -Wall. I have to
>> remember to
>> advise them to use -Wall and to fix all the warnings, which I sometimes
>> forget to do.
>
> Wouldn't it be better in a "moderately basic programming course" to
> provide standard canned scripts that set things up nicely for students
> including the switches they need? Indeed for such a course wouldn't it
> be better to use an appropriate IDE, so they could concentrate on the
> task at hand and not fiddling with commands. Yes, I think it is very
> important for students to learn what is going on, but you can't do
> everything at once in a basic course.
>
> And even in the context you give, surely it is not too much to expect
> a TA to remember important advice like this?

FWIW, in our "basic programming" course students have to hand their 
homework to an automated testing system which forces the compiler options 
we think useful, including all the relevant warning switches and -Werror. 
Of course, there is a web page explaining the meaning of the switches and 
TAs help with emphasizing their importance to students.  And indeed, you 
can't do everything in an 101 course, thus not much of this (helpful) 
information remains in their heads.  But it's better than nothing.

Andrey

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:17 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
>>
>> On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
>>>
>>> Well a lot of users have been burned by using optimization
>>> options, either becausae of compiler bugs, or because of bugs
>>> in their own code triggered by optimization. So the requirement
>>> of not using any optimization options is not that uncommon.
>>
>>
>> But no-optimizations (-O0) should not necessarily be the default
>> for these reasons.
>
>
> I think it is a problem that even at -O1 the debugger is
> seriously limited, especially for an inexperienced user.
>
> What is missing to me is a reasonable cleanup of the code that
> would remove some of the junk at -O0 but not impact debugging.
> In fact a reasonable criterion would be all the optimization
> that is cheap to do and does not affect debugging.
>
> Then I would make THAT the default (or simply redefine -O0
> to be this level, I see no real advantage in -O0 as it is now)

Fact is that -O1 pretty much enables random stuff without any
specific priorities (apart from making compile-time not too big).
It is definitely not "optimize but keep the program debuggable":

--
@opindex O1
Optimize.  Optimizing compilation takes somewhat more time, and a lot
more memory for a large function.

With @option{-O}, the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal of
compilation time.
--

It's on my large TODO list, somewhere at the bottom, to propose
to make -O1 stop after early optimizations and drop right to
expansion from there.  That would turn optimization expectations
upside-down of course, but early optimizations should be mostly
reducing code size (and thus increase compile speed) with
no fancy optimization that inhibit debugging (SRA, IPA-SRA,
switch conversion and function splitting are an exception,
but all but SRA are not enabled at -O1).  So we'd move to
compile-time and debuggability for -O1 (I'd expect compile time
that should be better or at least not a lot slower than -O0).

Richard.

Re: RFC: -Wall by default

[Robert Dewar]

> It's on my large TODO list, somewhere at the bottom, to propose
> to make -O1 stop after early optimizations and drop right to
> expansion from there.  That would turn optimization expectations
> upside-down of course, but early optimizations should be mostly
> reducing code size (and thus increase compile speed) with
> no fancy optimization that inhibit debugging (SRA, IPA-SRA,
> switch conversion and function splitting are an exception,
> but all but SRA are not enabled at -O1).  So we'd move to
> compile-time and debuggability for -O1 (I'd expect compile time
> that should be better or at least not a lot slower than -O0).

I am all in favor of such work, but I would approach it in two
steps. First make it a separate -O level, then depending on
how successful this is in practice, propose making -O1 mean
this new level.

If you do both steps at once, you get opposition on the basis
of change-is-bad, rather than to the substance of the new
level of optimization.
>
> Richard.

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 03:33 PM, Robert Dewar wrote:
>
> Wouldn't it be better in a "moderately basic programming course" to
> provide standard canned scripts that set things up nicely for students
> including the switches they need? Indeed for such a course wouldn't it
> be better to use an appropriate IDE, so they could concentrate on the
> task at hand and not fiddling with commands. Yes, I think it is very
> important for students to learn what is going on, but you can't do
> everything at once in a basic course.
>
> And even in the context you give, surely it is not too much to expect
> a TA to remember important advice like this?

They use an IDE, which is either Code-Blocks or Dev-C++, which run on
Windows, but these IDEs don't turn -Wall on by default. As for the advice
  to use -Wall, there is so much to advise  and so little time, and the 
sheer
mass of information confuses students. I'd have GCC emit more warnings
by default rather than explain what -Wall is  (and have half of them forget
that by the time they get to the computer).

After seeing the disaster of their first home assignment, students would
be more attentive to the advise regarding -Wall. It is much more effective
to wait for the submission of the first assignment and explain -Wall
afterwards. On the other hand, it had been far more effective had GCC
turned it on by default!

In my code I use -Wextra and find it very helpful, but I would not recommend
it to others since it requires to have a very strict coding style. I 
find it very
effective that it warns when a symbol in an inner context overshadows a
symbol in an outer context, or warns on unused parameters,  On the other
hand, it gets annoying at times. Nevertheless, it caught enough bugs to make
it worth the trouble.

Michael

Re: RFC: -Wall by default

[Basile Starynkevitch]

On Thu, Apr 05, 2012 at 03:28:54PM +0300, Michael Veksler wrote:
> On 04/05/2012 02:45 PM, Eric Botcazou wrote:
> >I personally don't buy the "can't remember" argument. When you use
> >GCC, you just have to remember -g, -O, -W and that's pretty much
> >it.

> Many of the students don't know of -Wall because they don't read the
> gcc manual,
> either because they are overwhelmed with assignments and exams, or because
> they are intimidated by big manuals written in technical English.
> Either way, many
> won't use -Wall unless they are told to.
> 
> My conclusion: it would be much better for beginners to have more
> warnings turned on.
> 

A possible solution might be to permit our spec file to turn on -Wall by default (it is probably possible today, or easily patchable) and more importantly to document how to customize the spec file to make -Wall by default.

But I do agree that newbies need -Wall even more than others, but don't know about it.

Cheers

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: RFC: -Wall by default

[Erik Trulsson]

On Thu, Apr 05, 2012 at 02:30:10PM +0200, Vincent Lefevre wrote:
> On 2012-04-05 08:17:57 -0400, Robert Dewar wrote:
> > On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
> > >But no-optimizations (-O0) should not necessarily be the default
> > >for these reasons.
> > 
> > I think it is a problem that even at -O1 the debugger is
> > seriously limited, especially for an inexperienced user.
> 
> OK.
> 
> Now, AFAIK, compiling and running programs occurs much more often
> than debugging them. So, I would say that -O1 should be the default.
> The user can still recompile his program with -O0 (or future better
> option) if he needs to run the debugger on it; if he doesn't know
> that, there should be some feature in the debugger to tell the user
> what to do.

Better would be to improve the output from -O1 so it is usable by a
debugger, even if this might require generating slightly less optimized
code at -O1 than is done now.

> 
> > What is missing to me is a reasonable cleanup of the code that
> > would remove some of the junk at -O0 but not impact debugging.
> > In fact a reasonable criterion would be all the optimization
> > that is cheap to do and does not affect debugging.
> 
> I think that for debugging, there should be a single option to
> disable optimizations that are unsafe for the debugger and that
> would add debugging information (such as what -g does). In short,
> the user would just have to add this option, which should do all
> the magic for debugging.

No, absolutely not. Turning on debugging should not change what the
generated code looks like.  Depending on the bug it is quite possible
for changes in optimization to hide the symptoms of the bug, thereby
making it more difficult to track down the bug.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:49 PM, Robert Dewar <dewar@adacore.com> wrote:
>
>> It's on my large TODO list, somewhere at the bottom, to propose
>> to make -O1 stop after early optimizations and drop right to
>> expansion from there.  That would turn optimization expectations
>> upside-down of course, but early optimizations should be mostly
>> reducing code size (and thus increase compile speed) with
>> no fancy optimization that inhibit debugging (SRA, IPA-SRA,
>> switch conversion and function splitting are an exception,
>> but all but SRA are not enabled at -O1).  So we'd move to
>> compile-time and debuggability for -O1 (I'd expect compile time
>> that should be better or at least not a lot slower than -O0).
>
>
> I am all in favor of such work, but I would approach it in two
> steps. First make it a separate -O level, then depending on
> how successful this is in practice, propose making -O1 mean
> this new level.
>
> If you do both steps at once, you get opposition on the basis
> of change-is-bad, rather than to the substance of the new
> level of optimization.

Ok, that were my thoughts as well.  It was suggested to add -Og
in the past, which, at some point could become the default
for a plain 'gcc' invocation.  It happens that people care for -O0
and that -O2 is tuned quite well - -O1 did not see any adjustments
in the last 10 years I think (well, not based on any benchmarking at least).

Not sure if inflation of -O variants will be well-received though ;)  Re-using
-O looked appealing to me ...

Richard.

>>
>>
>> Richard.
>
>

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 03:43 PM, Andrey Belevantsev wrote:
> FWIW, in our "basic programming" course students have to hand their 
> homework to an automated testing system which forces the compiler 
> options we think useful, including all the relevant warning switches 
> and -Werror. Of course, there is a web page explaining the meaning of 
> the switches and TAs help with emphasizing their importance to 
> students.  And indeed, you can't do everything in an 101 course, thus 
> not much of this (helpful) information remains in their heads.  But 
> it's better than nothing.

We don't have such an automated testing system at our faculty (IE). I 
had to write my own
automated testing which took me too much time to complete. Sometimes I 
excel at the NIH
syndrome, well at least I learned python on the way.

Anyway this is not quite a 101 course, since it also introduces low 
level stuff like 2's complement,
FP representation, caches, assembly, profiling, concurrency, address 
translation, and more. As
I said, too much in a short time. Remembering a specific GCC flag will 
be lost in the noise for too
many students, especially if they think that they will never work again 
with GCC after the course.
Which is probably correct for quite a few of them as this is Industrial 
Engineering & Management,
not CS or EE.

Michael

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:59 AM, Michael Veksler wrote:

> They use an IDE, which is either Code-Blocks or Dev-C++, which run on
> Windows, but these IDEs don't turn -Wall on by default. As for the advice
>    to use -Wall, there is so much to advise  and so little time, and the
> sheer
> mass of information confuses students. I'd have GCC emit more warnings
> by default rather than explain what -Wall is  (and have half of them forget
> that by the time they get to the computer).

I would focus on the IDE here, it is an obvious defect for an IDE not
to be able to control the default switches IMO.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 15:09:32 +0200, Erik Trulsson wrote:
> Better would be to improve the output from -O1 so it is usable by a
> debugger, even if this might require generating slightly less optimized
> code at -O1 than is done now.

This contradicts what you say below.

> > > What is missing to me is a reasonable cleanup of the code that
> > > would remove some of the junk at -O0 but not impact debugging.
> > > In fact a reasonable criterion would be all the optimization
> > > that is cheap to do and does not affect debugging.
> > 
> > I think that for debugging, there should be a single option to
> > disable optimizations that are unsafe for the debugger and that
> > would add debugging information (such as what -g does). In short,
> > the user would just have to add this option, which should do all
> > the magic for debugging.
> 
> No, absolutely not. Turning on debugging should not change what the
> generated code looks like.

For instance, the effect of a bug appears only with -O3.
Then you have 2 possibilities:
1. The debugger can cope with such optimization levels. So, -O1
   doesn't need to be modified.
2. The debugger cannot cope with such optimization levels, and you
   are forced anyway to change what the generated code looks like
   in order to try to debug it (or improve the debugger to be in
   case 1, if possible).

> Depending on the bug it is quite possible for changes in
> optimization to hide the symptoms of the bug, thereby making it more
> difficult to track down the bug.

I agree, but this is not by removing some default optimizations
that you would solve the problems due to a bug that appears when
the user chooses to use a higher optimization level.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 6:45 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> From developer perspective, we think that -Wall is so simple to
>> remember, because
>> in fact, we are used to handle so many complex things that this one five
>> letter is nothing.  However, users aren't as sophisticated as we would like
>> them to (I am not being condescending.)  The way we have to approach this
>> is how can we satisfy persistent demands and still remain competitive.
>
> I personally don't buy the "can't remember" argument.

At least, on three occasions this week, it was made to me in person by competent
people (the last was "I forgot what actually is doing").  These people
use several tools
for programming, including several compilers.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

this is drifting, but since we talking about teaching (which is part of my
daytime job)

On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar <dewar@adacore.com> wrote:

> Wouldn't it be better in a "moderately basic programming course" to
> provide standard canned scripts that set things up nicely for students
> including the switches they need?

you are assuming that all students have the same programming environement
or that we can force them, or that the environment they are programming in
can run "standard canned scripts that set things up".  The reality is that far
from these ideal situations.

> Indeed for such a course wouldn't it
> be better to use an appropriate IDE, so they could concentrate on the
> task at hand and not fiddling with commands. Yes, I think it is very
> important for students to learn what is going on, but you can't do
> everything at once in a basic course.

Where I teach I cannot MANDATE a particular IDE and have my course approved
by the faculty senate.


>
> And even in the context you give, surely it is not too much to expect
> a TA to remember important advice like this?

Re: RFC: -Wall by default

[Pedro Lamarão]

On 04/05/2012 11:29 AM, Gabriel Dos Reis wrote:
> this is drifting, but since we talking about teaching (which is part of my
> daytime job)
>
> On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar<dewar@adacore.com>  wrote:
>
>> Wouldn't it be better in a "moderately basic programming course" to
>> provide standard canned scripts that set things up nicely for students
>> including the switches they need?
>
> you are assuming that all students have the same programming environement
> or that we can force them, or that the environment they are programming in
> can run "standard canned scripts that set things up".  The reality is that far
> from these ideal situations.

If people should be wrapped inside scripts which enable -Wall for them, 
just enable -Wall for them, right?

Eclipse CDT and Visual Studio turn warnings on by default for new 
projects. You could ask them if anyone is requesting this default to be 
turned off.

--
  P.

Re: RFC: -Wall by default

[Andrew Haley]

On 04/05/2012 01:28 PM, Michael Veksler wrote:

> As for specific warnings, I hate that the the code (a&&b || c&&d),
> which did not cause a warning on older gcc version now gives a
> warning. I would not want it on by default since it forces users to
> write too many parentheses in ((a&&b)||(c&&d)) which makes the
> expression less readable. What next? Warn about (a*b+c*d) ? I would
> hate to write ((a*b)+(c*d)).
> 
> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
> least as common as * vs. + that programmers ought to know them.

Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
warned for arithmetic.

Andrew.

Re: RFC: -Wall by default

[Ian Lance Taylor]

Andrew Haley <aph@redhat.com> writes:

> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>
>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>> which did not cause a warning on older gcc version now gives a
>> warning. I would not want it on by default since it forces users to
>> write too many parentheses in ((a&&b)||(c&&d)) which makes the
>> expression less readable. What next? Warn about (a*b+c*d) ? I would
>> hate to write ((a*b)+(c*d)).
>> 
>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
>> least as common as * vs. + that programmers ought to know them.
>
> Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
> warned for arithmetic.

This one is an interesting case, since there are strong arguments on
both sides.

I enabled the C++ warning about the precedence of && and || (it's been
in C for many years).  It found real bugs in real code, bugs that had
existed for years.

Ian

Re: RFC: -Wall by default

[Andrew Haley]

On 04/11/2012 05:18 PM, Ian Lance Taylor wrote:
> Andrew Haley <aph@redhat.com> writes:
> 
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc version now gives a
>>> warning. I would not want it on by default since it forces users to
>>> write too many parentheses in ((a&&b)||(c&&d)) which makes the
>>> expression less readable. What next? Warn about (a*b+c*d) ? I would
>>> hate to write ((a*b)+(c*d)).
>>>
>>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
>>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
>>> least as common as * vs. + that programmers ought to know them.
>>
>> Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
>> warned for arithmetic.
> 
> This one is an interesting case, since there are strong arguments on
> both sides.
> 
> I enabled the C++ warning about the precedence of && and || (it's been
> in C for many years).  It found real bugs in real code, bugs that had
> existed for years.

It's the balance with false positives, as usual.  If you're looking
for a good example of a warning that is useful but still triggers with
perfectly legal (and reasonable) code, this is a great example.

Andrew.

Re: RFC: -Wall by default

[Peter Bigot]

On Wed, Apr 11, 2012 at 11:18 AM, Ian Lance Taylor <iant@google.com> wrote:
> Andrew Haley <aph@redhat.com> writes:
>
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc version now gives a
>>> warning. I would not want it on by default since it forces users to
>>> write too many parentheses in ((a&&b)||(c&&d)) which makes the
>>> expression less readable. What next? Warn about (a*b+c*d) ? I would
>>> hate to write ((a*b)+(c*d)).
>>>
>>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
>>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
>>> least as common as * vs. + that programmers ought to know them.
>>
>> Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
>> warned for arithmetic.
>
> This one is an interesting case, since there are strong arguments on
> both sides.
>
> I enabled the C++ warning about the precedence of && and || (it's been
> in C for many years).  It found real bugs in real code, bugs that had
> existed for years.

Indeed; although I follow GCC conventions while writing code for integration
into GCC, in my own code I'd much rather write ((a*b)+(c*d)) and deal with
any readability issues by adding whitespace.

Making the intent explicit seems safer than making assumptions about the
expertise level of the people who will be reading and maintaining the code,
or adding to the cognitive load of a maintainer who does remember the
precedence rules.

(Not even hinting for a change in GCC style: it's your bikeshed, I just
visit once in a while.)

Peter

Re: RFC: -Wall by default

[Robert Dewar]

O
> This one is an interesting case, since there are strong arguments on
> both sides.
>
> I enabled the C++ warning about the precedence of&&  and || (it's been
> in C for many years).  It found real bugs in real code, bugs that had
> existed for years.

I think for ordinary programmers, the fact that AND binds more tightly
than OR is not well known. After all it makes no intrinsic sense (the
connection via boolean logic with * and + is obscure to say the least).

I am in favor of enabling this warning.

P.S. I like Ada's viewpoint here of requiring parenthesization in
this case.
>
> Ian

Re: RFC: -Wall by default

[Fabien Chêne]

2012/4/11 Ian Lance Taylor <iant@google.com>:
> Andrew Haley <aph@redhat.com> writes:
>
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc version now gives a
>>> warning. I would not want it on by default since it forces users to
>>> write too many parentheses in ((a&&b)||(c&&d)) which makes the
>>> expression less readable. What next? Warn about (a*b+c*d) ? I would
>>> hate to write ((a*b)+(c*d)).
>>>
>>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
>>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
>>> least as common as * vs. + that programmers ought to know them.
>>
>> Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
>> warned for arithmetic.
>
> This one is an interesting case, since there are strong arguments on
> both sides.
>
> I enabled the C++ warning about the precedence of && and || (it's been
> in C for many years).  It found real bugs in real code, bugs that had
> existed for years.

I've got a radically different experience here, real bugs were
introduced while trying to remove this warning, and as far as I can
tell, I've never found any bugs involving precedence of && and || --
in the code I'm working on --, whose precedence is really well known
from everyone. In the real life, things are not as simple as (a && b)
|| ( c && d), some checks usually lie over more than five lines. This
warning applied to such checks are really a pain to remove.

We shall definitely have an option to remove this very warning,
without  getting rid of the whole sets of usefull warnings embedded in
-Wparentheses.

-- 
Fabien

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 4:55 AM, Fabien Chêne wrote:

> I've got a radically different experience here, real bugs were
> introduced while trying to remove this warning, and as far as I can
> tell, I've never found any bugs involving precedence of&&  and || --
> in the code I'm working on --, whose precedence is really well known
> from everyone.

You simply can't make a claim on behalf of everyone like this, and it's
very easy to prove you wrong, i personally know many competent 
programmers who do NOT know this rule.

  In the real life, things are not as simple as (a&&  b)
> || ( c&&  d), some checks usually lie over more than five lines. This
> warning applied to such checks are really a pain to remove.

a) complex conditionals over five lines are a bit of a menace
anyway, but ones that rely on knowing this precedence rule are
a true menace if you ask me.

b) it should be trivial to remove this warning, as it is a simple
automatic refactoring that should be easily done with a tool (most
certainly the automatic refactoring available in GPS for GNAT would
take care of this, if it needed to, which it does not, since in Ada
parentheses are required in such cases (the designers of Ada most
certainly disagreed with you that everyone knows this warning).
>
> We shall definitely have an option to remove this very warning,
> without  getting rid of the whole sets of usefull warnings embedded in
> -Wparentheses.

Yes, that seems a perfectly reasonable proposition. In GNAT there is
a very general mechanism to suppress any specific warning (pragma
Warnings (Off, string), where string matches the text of the message
you want to suppress)) as well as a long list of specific warnings
switches, similar to what we have in GNU C.
>

Re: RFC: -Wall by default

[Miles Bader]

Robert Dewar <dewar@adacore.com> writes:
>> I've got a radically different experience here, real bugs were
>> introduced while trying to remove this warning, and as far as I can
>> tell, I've never found any bugs involving precedence of&&  and || --
>> in the code I'm working on --, whose precedence is really well known
>> from everyone.
>
> You simply can't make a claim on behalf of everyone like this, and it's
> very easy to prove you wrong, i personally know many competent
> programmers who do NOT know this rule.

... and it's quite possible that such bugs resulting from adding
parentheses means that the programmer "fixing" the code didn't
actually know the right precedence!

I think the relative precedence of * and + can be safely termed "very
well known", but in the case of && and ||, it's not so clear...

-miles

-- 
Brain, n. An apparatus with which we think we think.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 5:55 AM, Miles Bader wrote:

> ... and it's quite possible that such bugs resulting from adding
> parentheses means that the programmer "fixing" the code didn't
> actually know the right precedence!

or that the layout (which is what in practice we should rely on
to make things clear with or without the parentheses) was sloppy
or plain incorrect.
>
> I think the relative precedence of * and + can be safely termed "very
> well known", but in the case of&&  and ||, it's not so clear...

indeed

Re: RFC: -Wall by default

[Fabien Chêne]

2012/4/12 Robert Dewar <dewar@adacore.com>:
> On 4/12/2012 4:55 AM, Fabien Chêne wrote:
>
>> I've got a radically different experience here, real bugs were
>> introduced while trying to remove this warning, and as far as I can
>> tell, I've never found any bugs involving precedence of&&  and || --
>>
>> in the code I'm working on --, whose precedence is really well known
>> from everyone.
>
>
> You simply can't make a claim on behalf of everyone like this, and it's
> very easy to prove you wrong, i personally know many competent programmers
> who do NOT know this rule.

I should have said: from everyone with whom I work. I'm not claiming
that this warning is useless for everybody, I'm basically saying that
it is often a nuisance/risk to convert existing code to bypass this
warning.

>  In the real life, things are not as simple as (a&&  b)
>>
>> || ( c&&  d), some checks usually lie over more than five lines. This
>>
>> warning applied to such checks are really a pain to remove.
>
> a) complex conditionals over five lines are a bit of a menace
> anyway,

I agree, they are actually a menace, and I do not want to touch them
without a good reason. Adding parentheses does not improve
readability, nor does it solves bugs in my own experience. Anyway,
precedence rules have to be known in order to remove the warning.

>  but ones that rely on knowing this precedence rule are
> a true menace if you ask me.

G++ has not warned about this for decades, so whether or not people
assuming basic precedence rules to be known are a menace, code that
does not make precedence explicit, is quite common and we have to cope
with it. And hopefully I'd rather not fix it everywhere.

> b) it should be trivial to remove this warning, as it is a simple
> automatic refactoring that should be easily done with a tool (most
> certainly the automatic refactoring available in GPS for GNAT would
> take care of this, if it needed to, which it does not, since in Ada
> parentheses are required in such cases (the designers of Ada most
> certainly disagreed with you that everyone knows this warning).

If you are aware of a simple tool that do that for C++, I am all ears
... But I'd rather have a new option to disable it ;-)

-- 
Fabien

Re: RFC: -Wall by default

[Andrew Haley]

On 04/12/2012 10:46 AM, Robert Dewar wrote:
> On 4/12/2012 4:55 AM, Fabien Chêne wrote:
> 
>> I've got a radically different experience here, real bugs were
>> introduced while trying to remove this warning, and as far as I can
>> tell, I've never found any bugs involving precedence of&&  and || --
>> in the code I'm working on --, whose precedence is really well known
>> from everyone.
> 
> You simply can't make a claim on behalf of everyone like this, and it's
> very easy to prove you wrong, i personally know many competent 
> programmers who do NOT know this rule.

I realize that I am in danger of using the No True Scotsman argument,
but I think I'd have to question the "competent" assertion.  It's
rather like saying you know many competent carpenters who don't know
how to use a biscuit joiner: while they may be decent carpenters,
you'd have to ask how much carpentry they'd actually done.

I would also suggest that a competent programmer would know what they
don't know; when reading code they'd look it up, when writing code
they'd insert parentheses for clarity.

Andrew.


http://en.wikipedia.org/wiki/No_true_scotsman

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 6:44 AM, Andrew Haley wrote:

> I would also suggest that a competent programmer would know what they
> don't know; when reading code they'd look it up, when writing code
> they'd insert parentheses for clarity.

Yes, of course I 100% agree with that. But then by your definition
code that does not have the "parentheses for clarity" is written by
incompetent programmers, and it seems reasonable to have a warning
that warns them of this incompetence :-)

Re: RFC: -Wall by default

[Andrew Haley]

On 04/12/2012 02:03 PM, Robert Dewar wrote:
> On 4/12/2012 6:44 AM, Andrew Haley wrote:
> 
>> I would also suggest that a competent programmer would know what they
>> don't know; when reading code they'd look it up, when writing code
>> they'd insert parentheses for clarity.
> 
> Yes, of course I 100% agree with that. But then by your definition
> code that does not have the "parentheses for clarity" is written by
> incompetent programmers, and it seems reasonable to have a warning
> that warns them of this incompetence :-)

Sorry for the confusion: I intended to write

>> I would also suggest that your competent programmer would know what
>> they don't know; when reading code they'd look it up, when writing
>> code they'd insert parentheses for clarity.

Using two different definitions of "competent programmer" without
clarification makes me an incompetent writer, I suppose.  :-)

Andrew.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 9:30 AM, Andrew Haley wrote:

>
> Sorry for the confusion: I intended to write
>
>>> I would also suggest that your competent programmer would know what
>>> they don't know; when reading code they'd look it up, when writing
>>> code they'd insert parentheses for clarity.
>
> Using two different definitions of "competent programmer" without
> clarification makes me an incompetent writer, I suppose.  :-)
>
> Andrew.

The correct thing to write definitely does NOT depend on the
competence or otherwise of the writer. If putting in
parentheses adds to clarity, then everyone should do it
since you are writing code for other people to read,
not yourself.

Re: RFC: -Wall by default

[Andrew Haley]

On 04/12/2012 03:36 PM, Robert Dewar wrote:
> On 4/12/2012 9:30 AM, Andrew Haley wrote:
> 
>>>> I would also suggest that your competent programmer would know what
>>>> they don't know; when reading code they'd look it up, when writing
>>>> code they'd insert parentheses for clarity.
>>
>> Using two different definitions of "competent programmer" without
>> clarification makes me an incompetent writer, I suppose.  :-)
> 
> The correct thing to write definitely does NOT depend on the
> competence or otherwise of the writer. If putting in
> parentheses adds to clarity, then everyone should do it
> since you are writing code for other people to read,
> not yourself.

Certainly, everything that adds to clarity (and has no runtime costs!)
is desirable.  But adding parentheses may not add to clarity if doing
so also obfuscates the code.  There is a cost to the reader due to a
blizzard of syntactically redundant parentheses; if there weren't, we
wouldn't bother with operator precedence.

Ultimately, it's a matter of taste and experience.  I'm going to find
it hard to write for people who don't know the relative precedence of
& and | .

Andrew.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 10:48 AM, Andrew Haley wrote:

> Certainly, everything that adds to clarity (and has no runtime costs!)
> is desirable.  But adding parentheses may not add to clarity if doing
> so also obfuscates the code.  There is a cost to the reader due to a
> blizzard of syntactically redundant parentheses; if there weren't, we
> wouldn't bother with operator precedence.

Well I think blizzard is overblown. Ada requires these parentheses
and I never heard of anyone complaining of blizzards :-)
>
> Ultimately, it's a matter of taste and experience.  I'm going to find
> it hard to write for people who don't know the relative precedence of
> &  and | .

Well it's always a problem for programmers who know too much to write
code that can easily be read by everyone, in Ada we take the position
that readability is paramount, and we really don't care if programmers
find it harder to write readable code :-)
>
> Andrew.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 10:48 AM, Andrew Haley wrote:

> Ultimately, it's a matter of taste and experience.  I'm going to find
> it hard to write for people who don't know the relative precedence of
> &  and | .

There are probably some programmers who completely know ALL the operator
precedence rules in C. There are probably some subset of those who feel
free to write code that takes full advantage of these rules. I would
hate to read code written by such people :-)

Re: RFC: -Wall by default

[pcpa]

Robert Dewar escreveu:
> On 4/12/2012 10:48 AM, Andrew Haley wrote:
>
>> Ultimately, it's a matter of taste and experience.  I'm going to find
>> it hard to write for people who don't know the relative precedence of
>> &  and | .
>
> There are probably some programmers who completely know ALL the operator
> precedence rules in C. There are probably some subset of those who feel
> free to write code that takes full advantage of these rules. I would
> hate to read code written by such people :-)

  I know the different precedences (well I some/most times get confused
with the order of some because I almost always use parenthesis). I prefer
to think of && and || with same, left to right precedence.

  There are people that require (a)?(b):(c) to be in parenthesis because
they find the precedence rules confusing.

  And there are all the extra parenthesis added to avoid surprises after
macro expansion, but people usually do not read macro expansions :-)

Paulo

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 16:35, Robert Dewar wrote:
> On 4/12/2012 10:48 AM, Andrew Haley wrote:
> 
>> Ultimately, it's a matter of taste and experience.  I'm going to find
>> it hard to write for people who don't know the relative precedence of
>> &  and | .
> 
> There are probably some programmers who completely know ALL the operator
> precedence rules in C. There are probably some subset of those who feel
> free to write code that takes full advantage of these rules. I would
> hate to read code written by such people :-)

  I think it's worth suggesting, in the context of this discussion, that one
of the main purposes for which warnings exist in the first place is
*didactic*: they are very much intended to help teach the inexperienced about
the points of the language that they need to get straight in their heads, and
that their code /suggests/ that they haven't done so yet.

  For that reason, I think that it's OK to have false-positive or slightly
over-sensitive warnings; certainly you don't want the noise to drown out the
signal, but unless they actually really do flood it out then they're not
necessarily a terribly bad thing in their own right.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Chris Lattner]

On Apr 13, 2012, at 5:09 PM, NightStrike wrote:
> Can the -Winf option really happen?  It should be easy to make that
> turn on every -W option without having the manually list them and keep
> it up to date.  Like, it should be easy, I would hope, to make that be
> automatic.  Even if just used as a toy, I think this is a neat idea
> that would not require much work.

Clang has -Weverything, which really does turn on every warning:
http://clang.llvm.org/docs/UsersManual.html#diagnostics_enable_everything

People who like warnings (and like to know when a new build of the compiler adds something) really like this.   OTOH, being able to support this well requires that all warnings have an associated -Wno-XX flag associated with them.

-Chris

Re: RFC: -Wall by default

[NightStrike]

On Fri, Apr 13, 2012 at 12:46 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 13/04/2012 22:45, Oleg Smolsky wrote:
>> On 2012-04-11 01:50, Vincent Lefevre wrote:
>>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>>>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>>>
>>>>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>>>>> means something quite specific for compilers, and the warning switch
>>>>>> wouldn't have anything to do with standards conformance.
>>>>> -Wdefault
>>>>>
>>>>> might be better
>>>> except if people want warnings about "defaults" in C++11 (which can mean
>>>> lot of things).
>>> How about a warning level?
>>>
>>> -W0: no warnings (equivalent to -w)
>>> -W1: default
>>> -W2: equivalent to the current -Wall
>>> -W3: equivalent to the current -Wall -Wextra
>>>
>> This is exactly what Microsoft C++ compiler does and what their Visual
>> Studio IDE exposes in the UI. So, there is a reasonable precedent.
>
>  Exactly.  Would anyone really think it would be a good idea to just not have
> the -O<number> levels and expect every end user to mix-and-match from a huge
> set of somewhat unknown-and-unpredictable-just-from-the-names long and
> confusingly named individual optimisation suboptions?  I think -W levels is a
> new feature that we can easily retrofit on top of the existing structure
> without having to break or change anything that already works, and that would
> be equally as user-friendly and pragmatic as having -O levels has already
> shown itself to be.

First, I think the -Wn option is fantastic, and I look forward to seeing it.

Second, some questions.

With -O, it's often said that a given -On level does not correspond to
an equivalent list of -f options.  I believe even the manual states
that for instance -O2 is a bunch of -f's plus some other stuff that
you can't turn on without -O2.  Would warnings options avoid this?
IMO, that's a deficiency in -O, and meta options should be strictly
meta.  So I guess I'm really asking that the precedent be set that -Wn
is always an amalgamation of existing -W options, and that we avoid
the -On situation.

Can the -Winf option really happen?  It should be easy to make that
turn on every -W option without having the manually list them and keep
it up to date.  Like, it should be easy, I would hope, to make that be
automatic.  Even if just used as a toy, I think this is a neat idea
that would not require much work.

Would a plugin be able to add in -W's to a given level?  So like, I
want to use MyPlug, and that comes with it -WMyWarn.  I'd like my
plugin to be able to say that -W2 turns on -WMyWarn.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 5:39 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 22:36, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote:
>>> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>>>
>>>> I keep talking about useful *warnings*, you keep talking about *numbers*.
>>>  No you don't.  You said:
>>>
>>>>>>>>>> People easily associates some ordering to numbers (usually
>>>>>>>>>> the greater the better or in this case the worse) which
>>>>>>>>>> creates another set of confusion.
>>>  That is talking about numbers.
>>
>> And you were complaining about your comments being taken out of context?
>
>  Yes, I am, because that statement of your above _was_ the context for the
> whole rest of the discussion.

No, that is not correct.

> You were interrupting in between me saying "The
> situation is X" and my next sentence where I continued "Because of Y".  *You*
> were the one who said that the numbers were a problem because people would
> expect some kind of monotonic increase in warnings related to the numbers, I
> was the one who pointed out that the suggestion originally offered exactly
> matched that situation.
>
>  Seriously, if you think something like this:
>
>>>  Your argument makes no sense.
>>
>> Do you think that assertion makes sens when no evidence is
>> provided to support it?
>>
>>> > You said that there was a problem because
>>> > people will expect numbered -W options to be ordinal.
>
> ... is anything other than a pedantic interruption in the middle of a coherent
> argument, you have a communication problem.  The basic unit of meaning in
> English is the paragraph, you can't take part of it alone and expect it to
> make sense out of context, but if you're going to accuse me of doing the same,
> well, here's your entire original paragraph:
>
>> People easily associates some ordering to numbers (usually
>> the greater the better or in this case the worse) which
>> creates another set of confusion.  Geodelization is great
>> for machines, hardly so as human interface.
>
>  There was only one extra sentence in it in the first place, and that other
> sentence doesn't relate to the first sentence in any way,  so I did *not* take
> your idea out of any kind of context that could in any way have contributed to
>  its coherency.

Not just because you wanted to make it sound as if it did not
have any relation -- so that you can embark on your rhetoric --
means there was no relation.  If you want to talk about pedantic
interruption, why don't you start with what you see in the mirror?

>  So let's get this silly subthread back on track;

I do not believe you missed any effort to get credit here.

> here's the
> summary of where we're at, with all the sidetracks taken out:
>
>>>> > -W0: no warnings (equivalent to -w)
>>>> > -W1: default
>>>> > -W2: equivalent to the current -Wall
>>>> > -W3: equivalent to the current -Wall -Wextra
>>>
>>>   I like this suggestion a lot.
>>
>> People easily associates some ordering to numbers (usually
>> the greater the better or in this case the worse) which
>> creates another set of confusion.
>
>  My response to that is that is not a "set of confusion", because there is
> indeed an ordering to the numbers, with zero being less warnings and 3 being
> most warnings, and therefore it is not a source of confusion but actually a
> source of correct knowledge about what the situation actually would be, and
> therefore that using -W<number> in that way would be a good idea.  Now, I
> admit that I have assumed you meant "source of confusion" rather than "set of
> confusion", since the latter phrase means nothing in English, so if that's
> where our misunderstanding has arisen, and you meant something other, then
> please speak up now and make it clear what you actually meant to convey.
>
>    cheers,
>      DaveK
>

Re: RFC: -Wall by default

[Dave Korn]

On 13/04/2012 22:45, Oleg Smolsky wrote:
> On 2012-04-11 01:50, Vincent Lefevre wrote:
>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>>
>>>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>>>> means something quite specific for compilers, and the warning switch
>>>>> wouldn't have anything to do with standards conformance.
>>>> -Wdefault
>>>>
>>>> might be better
>>> except if people want warnings about "defaults" in C++11 (which can mean
>>> lot of things).
>> How about a warning level?
>>
>> -W0: no warnings (equivalent to -w)
>> -W1: default
>> -W2: equivalent to the current -Wall
>> -W3: equivalent to the current -Wall -Wextra
>>
> This is exactly what Microsoft C++ compiler does and what their Visual
> Studio IDE exposes in the UI. So, there is a reasonable precedent.

  Exactly.  Would anyone really think it would be a good idea to just not have
the -O<number> levels and expect every end user to mix-and-match from a huge
set of somewhat unknown-and-unpredictable-just-from-the-names long and
confusingly named individual optimisation suboptions?  I think -W levels is a
new feature that we can easily retrofit on top of the existing structure
without having to break or change anything that already works, and that would
be equally as user-friendly and pragmatic as having -O levels has already
shown itself to be.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 22:36, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote:
>> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>>
>>> I keep talking about useful *warnings*, you keep talking about *numbers*.
>>  No you don't.  You said:
>>
>>>>>>>>> People easily associates some ordering to numbers (usually
>>>>>>>>> the greater the better or in this case the worse) which
>>>>>>>>> creates another set of confusion.
>>  That is talking about numbers.
> 
> And you were complaining about your comments being taken out of context?

  Yes, I am, because that statement of your above _was_ the context for the
whole rest of the discussion.  You were interrupting in between me saying "The
situation is X" and my next sentence where I continued "Because of Y".  *You*
were the one who said that the numbers were a problem because people would
expect some kind of monotonic increase in warnings related to the numbers, I
was the one who pointed out that the suggestion originally offered exactly
matched that situation.

  Seriously, if you think something like this:

>>  Your argument makes no sense.
> 
> Do you think that assertion makes sens when no evidence is
> provided to support it?
> 
>> > You said that there was a problem because
>> > people will expect numbered -W options to be ordinal.

... is anything other than a pedantic interruption in the middle of a coherent
argument, you have a communication problem.  The basic unit of meaning in
English is the paragraph, you can't take part of it alone and expect it to
make sense out of context, but if you're going to accuse me of doing the same,
well, here's your entire original paragraph:

> People easily associates some ordering to numbers (usually
> the greater the better or in this case the worse) which
> creates another set of confusion.  Geodelization is great
> for machines, hardly so as human interface.

  There was only one extra sentence in it in the first place, and that other
sentence doesn't relate to the first sentence in any way, so I did *not* take
your idea out of any kind of context that could in any way have contributed to
its coherency.  So let's get this silly subthread back on track; here's the
summary of where we're at, with all the sidetracks taken out:

>>> > -W0: no warnings (equivalent to -w)
>>> > -W1: default
>>> > -W2: equivalent to the current -Wall
>>> > -W3: equivalent to the current -Wall -Wextra
>> 
>>   I like this suggestion a lot.
> 
> People easily associates some ordering to numbers (usually
> the greater the better or in this case the worse) which
> creates another set of confusion.

  My response to that is that is not a "set of confusion", because there is
indeed an ordering to the numbers, with zero being less warnings and 3 being
most warnings, and therefore it is not a source of confusion but actually a
source of correct knowledge about what the situation actually would be, and
therefore that using -W<number> in that way would be a good idea.  Now, I
admit that I have assumed you meant "source of confusion" rather than "set of
confusion", since the latter phrase means nothing in English, so if that's
where our misunderstanding has arisen, and you meant something other, then
please speak up now and make it clear what you actually meant to convey.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Oleg Smolsky]

On 2012-04-11 01:50, Vincent Lefevre wrote:
> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>
>>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>>> means something quite specific for compilers, and the warning switch
>>>> wouldn't have anything to do with standards conformance.
>>> -Wdefault
>>>
>>> might be better
>> except if people want warnings about "defaults" in C++11 (which can mean
>> lot of things).
> How about a warning level?
>
> -W0: no warnings (equivalent to -w)
> -W1: default
> -W2: equivalent to the current -Wall
> -W3: equivalent to the current -Wall -Wextra
>
This is exactly what Microsoft C++ compiler does and what their Visual 
Studio IDE exposes in the UI. So, there is a reasonable precedent.

Oleg.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/13/2012 2:03 AM, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> End of thread for me, remove me from the reply lists, thanks
>> discussion is going nowhere, at this stage my vote is for
>> no change whatever in the way warnings are handled.
>
> I was asked "wassup with Robert?".  All I can say s that
> it is a decade-old relationship :-)
>
> -- Gaby

Nothing up, just felt nothing more was worth saying on this
thread, no point in just getting into the mode of repeating
stuff going nowhere.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar <dewar@adacore.com> wrote:
> End of thread for me, remove me from the reply lists, thanks
> discussion is going nowhere, at this stage my vote is for
> no change whatever in the way warnings are handled.

I was asked "wassup with Robert?".  All I can say s that
it is a decade-old relationship :-)

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

End of thread for me, remove me from the reply lists, thanks
discussion is going nowhere, at this stage my vote is for
no change whatever in the way warnings are handled.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:42 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote:
>
>> It isn't non-sense just because you decide so or you don't like the
>> observation.
>>
>>>  and
>>> nonsense now, this has nothing to do with incompleteness!
>
>
> I think you don't know what incompleteness is about, yes, it is

Do not allow yourself to be easily confused by misunderstanding
of Geodelization, a *process* of assigning numbers to entities

   http://demonstrations.wolfram.com/Goedelization/
   http://en.wikipedia.org/wiki/Turing%27s_proof

and make statement only in terms of those numbers and the incompleteness
theorems themselves, lest you might give the impression that you do not
know what you are talking about and all you need as evidence of target
of your message is to look in mirror.

-- Gaby

> nonsense, because no one can make any sense out of it except you
> and you refuse to elaborate or explain beyond just repeating
> the observation. Feel free to explain.
>>>>
>>>>
>>>>
>>>> -- Gaby
>>>
>>>
>>>
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote:

> It isn't non-sense just because you decide so or you don't like the observation.
>
>>   and
>> nonsense now, this has nothing to do with incompleteness!

I think you don't know what incompleteness is about, yes, it is
nonsense, because no one can make any sense out of it except you
and you refuse to elaborate or explain beyond just repeating
the observation. Feel free to explain.
>>>
>>>
>>> -- Gaby
>>
>>

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:38 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote:
>
>>>  There's nothing more ambiguous than saying that something is final in a
>>> world where perfection is never achieved.  That's why software has
>>> monotonically increasing version numbers, instead of just one that means
>>> "this
>>> is done now".
>>
>>
>> As I observed earlier, Geodelization is great for machines.
>
>
> You observed this before, but it was nonsense then

It isn't non-sense just because you decide so or you don't like the observation.

>  and
> nonsense now, this has nothing to do with incompleteness!
>>
>>
>> -- Gaby
>
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote:

>>   There's nothing more ambiguous than saying that something is final in a
>> world where perfection is never achieved.  That's why software has
>> monotonically increasing version numbers, instead of just one that means "this
>> is done now".
>
> As I observed earlier, Geodelization is great for machines.

You observed this before, but it was nonsense then and
nonsense now, this has nothing to do with incompleteness!
>
> -- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:30 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 12 April 2012 16:49, Gabriel Dos Reis wrote:
>>> It would even allow -Winf for the
>>> sometimes-requested-but-probably-not-actually-useful
>>> -Wreally-really-all that turns on *all* possible warnings.  Or
>>> -Wover9000.
>>
>> Do we have bugzilla entry for that?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and its dup.
>
> I thought I remembered another one with a subject like "-Wall isn't"
> but I can't find it now.

Thank you,

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>
>> I keep talking about useful *warnings*, you keep talking about *numbers*.
>
>  No you don't.  You said:
>
>>>>>>>> People easily associates some ordering to numbers (usually
>>>>>>>> the greater the better or in this case the worse) which
>>>>>>>> creates another set of confusion.
>
>  That is talking about numbers.

And you were complaining about your comments being taken out of context?

>   I'm not going to bother reading the rest of
> your email, you're just being argumentative and misunderstanding on purpose.
>
>    DaveK.
>

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 3:56 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 17:03, Gabriel Dos Reis wrote:
>>  There is
>> little ambiguity left by -Wreally-all-of-them-damn-it  :-)
>
>  Actually, no, as anyone could tell you who before they discovered version
> control used to have lots of files lying around called "foo.final.c",
> "foo.final.reallyfinal.c", "foo.final.updated.reallyfinalthistime.c", and so
> on; in other words, I think that after a few years have passed, we would find
> that we've been persuaded to add -Wreally-really-all-of-them-damn-it,
> -Wreally-really-all-no-actually-all-including-everything, and
> -Wreally-really-all-of-them-damn-it-no-i-really-did-mean-all-of-them-even-including-the-really-unexpected-ones.

But we are no longer in the era that forms the basis of your analogy :-)

>
>  There's nothing more ambiguous than saying that something is final in a
> world where perfection is never achieved.  That's why software has
> monotonically increasing version numbers, instead of just one that means "this
> is done now".

As I observed earlier, Geodelization is great for machines.

-- Gaby

Re: RFC: -Wall by default

[Jonathan Wakely]

On 12 April 2012 16:49, Gabriel Dos Reis wrote:
>> It would even allow -Winf for the
>> sometimes-requested-but-probably-not-actually-useful
>> -Wreally-really-all that turns on *all* possible warnings.  Or
>> -Wover9000.
>
> Do we have bugzilla entry for that?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and its dup.

I thought I remembered another one with a subject like "-Wall isn't"
but I can't find it now.

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 16:47, Gabriel Dos Reis wrote:

> I keep talking about useful *warnings*, you keep talking about *numbers*.

  No you don't.  You said:

>>>>>>> People easily associates some ordering to numbers (usually
>>>>>>> the greater the better or in this case the worse) which
>>>>>>> creates another set of confusion.

  That is talking about numbers.  I'm not going to bother reading the rest of
your email, you're just being argumentative and misunderstanding on purpose.

    DaveK.

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 17:03, Gabriel Dos Reis wrote:
>  There is
> little ambiguity left by -Wreally-all-of-them-damn-it  :-)

  Actually, no, as anyone could tell you who before they discovered version
control used to have lots of files lying around called "foo.final.c",
"foo.final.reallyfinal.c", "foo.final.updated.reallyfinalthistime.c", and so
on; in other words, I think that after a few years have passed, we would find
that we've been persuaded to add -Wreally-really-all-of-them-damn-it,
-Wreally-really-all-no-actually-all-including-everything, and
-Wreally-really-all-of-them-damn-it-no-i-really-did-mean-all-of-them-even-including-the-really-unexpected-ones.

  There's nothing more ambiguous than saying that something is final in a
world where perfection is never achieved.  That's why software has
monotonically increasing version numbers, instead of just one that means "this
is done now".

    cheers,
      DaveK

Re: RFC: -Wall by default

[Pedro Alves]

On 04/12/2012 04:52 PM, Gabriel Dos Reis wrote:

> On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote:
>>
>>> because -Os says it optimizes for size, the expectation is clear.
>>> -O3 does not necessarily give better optimization than -O2.
>>
>>
>> No, but it does mean that GCC turns on more optimization options.
>>
>> "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions,
>> -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. "
> 
> I think we have perverted the meaning of "optimize yet more", and optimize
> yet more does not yield better/faster code :-)


Sure, so that phrase in the documentation could be improved/replaced, or even removed.
The rest of the paragraph looks quite clear enough.

> Yes, I understand the transformations; that does not justify for the awkward
> user-interface.


So stop thinking in terms of -O, if it helps.  Maybe think in terms of -glevel?

 "Request debugging information and also use level to specify how much information. The default level is 2."

or just consider it on its own merits:

  -W0 no warning options enabled.  -W1, more warning options enabled than -W0.  -W2, more
  warning options enabled than -W1.  -WN, more warning options enabled than -WN-1.

I fail to see why is that awkward?

-- 
Pedro Alves

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:49 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 12 April 2012 16:33, Robert Dewar wrote:
>>>
>>> For warnings you put a higher number to get more warnings. Yes,
>>> you may find that you get too many warnings and they are not
>>> useful. Remedy: reduce the number after -W :-)
>>
>> It would even allow -Winf for the
>> sometimes-requested-but-probably-not-actually-useful
>> -Wreally-really-all that turns on *all* possible warnings.  Or
>> -Wover9000.
>
> Do we have bugzilla entry for that?
> -- Gaby

I forgot the remark about -Wover9000:  for many GCC users
(that I eye-witnessed), not only -On is supposed to optimize more,
but n can go beyond 999999 and it will give you better code than
99999 or 3.  One can argue they should be reading the manual,
but that is the whole point: many of them don't read the manual;
they look at a switch name and draw inference from there.  There is
little ambiguity left by -Wreally-all-of-them-damn-it  :-)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote:
>
>> because -Os says it optimizes for size, the expectation is clear.
>> -O3 does not necessarily give better optimization than -O2.
>
>
> No, but it does mean that GCC turns on more optimization options.
>
> "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions,
> -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. "

I think we have perverted the meaning of "optimize yet more", and optimize
yet more does not yield better/faster code :-)
Yes, I understand the transformations; that does not justify for the awkward
user-interface.

>
> Just like -W3 wouldn't necessarily generate more warnings on
> your code than -W1, perhaps because your code is
> already "clean" enough.  It would simply be documented as:
>
> "-W3: Warn yet more.  -W3 turns on all warnings specified by -W2 and also ...".
>
> I'll also note the parallel with -glevel, not just -O.
>
> So, 'gcc -glevel -Wlevel -Olevel' feels quite natural to me.
>
> --
> Pedro Alves

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 12 April 2012 16:33, Robert Dewar wrote:
>>
>> For warnings you put a higher number to get more warnings. Yes,
>> you may find that you get too many warnings and they are not
>> useful. Remedy: reduce the number after -W :-)
>
> It would even allow -Winf for the
> sometimes-requested-but-probably-not-actually-useful
> -Wreally-really-all that turns on *all* possible warnings.  Or
> -Wover9000.

Do we have bugzilla entry for that?
-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:24 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 16:06, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>>>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>>>>>> People easily associates some ordering to numbers (usually
>>>>>> the greater the better or in this case the worse) which
>>>>>> creates another set of confusion.
>>>>>  What's the problem?  The greater the number, the more warnings you get.  Simple.
>>>> Not necessarily.
>>>  Your argument makes no sense.
>>
>> Do you think that assertion makes sens when no evidence is
>> provided to support it?
>
>  My assertion was backed up by the sentences immediately after it, you can't
> just take it out of context and expect it to stand by yourself.  Here's the
> evidence coming up right now:
>
>>> You said that there was a problem because
>>> people will expect numbered -W options to be ordinal.
>>
>> What is nonsensical there?
>
>  Well stop interrupting and let me finish!  The very next sentence points out
> what is nonsensical about your statement:
>
>>> But they *are* ordinal.
>>
>> Now?  What is the order?
>
>  Zero, then one, then two, then three.  Are we having a language difficulty
> here?  You can't really be asking me what the ordinal sequence of the integers is.

I keep talking about useful *warnings*, you keep talking about *numbers*.

>
>>>  So people's expectations will be correct.  You haven't said anything about
>>> where the problem is yet, you've just asserted that there will be one without
>>> demonstration or evidence, so again I ask: What's the problem?
>>
>> You said the greater the number the more warnings you get, but you did not
>> show that would happen, so you have not shown that would necessarily happen.
>> What is nonsensical there?
>
>  You appear to have forgotten what we're talking about, so let me remind you:

I did not forget about it, if you had a doubt.

>>>>>> -W0: no warnings (equivalent to -w)
>>>>>> -W1: default
>>>>>> -W2: equivalent to the current -Wall
>>>>>> -W3: equivalent to the current -Wall -Wextra

I have given up on touching -Wall in any menaingful way
(either turning it on by default or moving warnings out of it, e.g.
-Wununsed).  Other useful warnings are left out of this scheme

>
>  There will be more warnings the greater the number because that is how it
> was defined to work.  The "default" will be the suggestion we've been
> discussing so far, i.e. effectively -Wall with a few of the less useful
> warnings removed.
>
>>>  It works just fine for -O,
>>
>> Exactly what happens with -O?  -On does not necessarily
>> generate faster or better code when n is higher.
>
>  Exactly, just like how it would be with warnings.

If you agree with that, then that is even more reason I am not convinced
by the scheme.  I would rather see a scheme that gives more useful warnings
than just cranking up warnings, just any warning to get higher number.
 I suspect
that is the real issue, not language issue.

>  -On when n is higher uses
> more optimisations, some of which may be problematic - we're warned that -O3
> may be unstable, and similarly -W3 may turn on warnings that are more of a
> hinderance than a help.

yes, I am unkeen on repeating that.


>
>    cheers,
>      DaveK
>
>

Re: RFC: -Wall by default

[Pedro Alves]

On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote:

> because -Os says it optimizes for size, the expectation is clear.
> -O3 does not necessarily give better optimization than -O2.


No, but it does mean that GCC turns on more optimization options.

"Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions,
-funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. "

Just like -W3 wouldn't necessarily generate more warnings on
your code than -W1, perhaps because your code is
already "clean" enough.  It would simply be documented as:

"-W3: Warn yet more.  -W3 turns on all warnings specified by -W2 and also ...".

I'll also note the parallel with -glevel, not just -O.

So, 'gcc -glevel -Wlevel -Olevel' feels quite natural to me.

-- 
Pedro Alves

Re: RFC: -Wall by default

[Jonathan Wakely]

On 12 April 2012 16:33, Robert Dewar wrote:
>
> For warnings you put a higher number to get more warnings. Yes,
> you may find that you get too many warnings and they are not
> useful. Remedy: reduce the number after -W :-)

It would even allow -Winf for the
sometimes-requested-but-probably-not-actually-useful
-Wreally-really-all that turns on *all* possible warnings.  Or
-Wover9000.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 11:23 AM, Gabriel Dos Reis wrote:

>> less warnings to more warnings, what could be more
>> ordered than that!
>
> What exactly do you put in -Wn to make it give *more* warning?
> I can think of a reduced number of switch that would give you
> more warning on a specific program without them being terribly
> useful.

It's JUST like the optimization case, you use a higher number
to get more optimization. Yes, there may be cases where this
hurts (we have seen cases where -O3 is slower than -O2
due to cache effects)

For warnings you put a higher number to get more warnings. Yes,
you may find that you get too many warnings and they are not
useful. Remedy: reduce the number after -W :-)

>> -On means more optimizations for higher n, simple enough?
>
> like the traditional -O2 vs. -O3?

Right, -O3 does more optimziations than -O2. Of course there
might be cases where this doesn't help. I bet if you look
hard enough you will find cases where -O1 code is slower
than -O0.

For -O, we do not guarantee that a higher number means faster code,
just that more optimizations are applied.

for -W, we do not guarantee that a higher number means a more
useful set of warnings, just more of them.

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 16:06, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>>>>> People easily associates some ordering to numbers (usually
>>>>> the greater the better or in this case the worse) which
>>>>> creates another set of confusion.
>>>>  What's the problem?  The greater the number, the more warnings you get.  Simple.
>>> Not necessarily.
>>  Your argument makes no sense.
> 
> Do you think that assertion makes sens when no evidence is
> provided to support it?

  My assertion was backed up by the sentences immediately after it, you can't
just take it out of context and expect it to stand by yourself.  Here's the
evidence coming up right now:

>> You said that there was a problem because
>> people will expect numbered -W options to be ordinal.
> 
> What is nonsensical there?

  Well stop interrupting and let me finish!  The very next sentence points out
what is nonsensical about your statement:

>> But they *are* ordinal.
> 
> Now?  What is the order?

  Zero, then one, then two, then three.  Are we having a language difficulty
here?  You can't really be asking me what the ordinal sequence of the integers is.

>>  So people's expectations will be correct.  You haven't said anything about
>> where the problem is yet, you've just asserted that there will be one without
>> demonstration or evidence, so again I ask: What's the problem?
> 
> You said the greater the number the more warnings you get, but you did not
> show that would happen, so you have not shown that would necessarily happen.
> What is nonsensical there?

  You appear to have forgotten what we're talking about, so let me remind you:

>>>>> -W0: no warnings (equivalent to -w)
>>>>> -W1: default
>>>>> -W2: equivalent to the current -Wall
>>>>> -W3: equivalent to the current -Wall -Wextra

  There will be more warnings the greater the number because that is how it
was defined to work.  The "default" will be the suggestion we've been
discussing so far, i.e. effectively -Wall with a few of the less useful
warnings removed.

>>  It works just fine for -O,
> 
> Exactly what happens with -O?  -On does not necessarily
> generate faster or better code when n is higher.

  Exactly, just like how it would be with warnings.  -On when n is higher uses
more optimisations, some of which may be problematic - we're warned that -O3
may be unstable, and similarly -W3 may turn on warnings that are more of a
hinderance than a help.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:16 AM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote:
>
>> What is nonsensical there?
>>
>>> But they *are* ordinal.
>>
>>
>> Now?  What is the order?
>
>
> less warnings to more warnings, what could be more
> ordered than that!

What exactly do you put in -Wn to make it give *more* warning?
I can think of a reduced number of switch that would give you
more warning on a specific program without them being terribly
useful.

>
>
>>>  It works just fine for -O,
>>
>>
>> Exactly what happens with -O?  -On does not necessarily
>> generate faster or better code when n is higher.
>
> -On means more optimizations for higher n, simple enough?

like the traditional -O2 vs. -O3?

>
>>
>> In fact, -Os is a perfect example of a short name that is NOT
>> a number.
>
> right, because -Os lies outside the more optimizations for
> higher values rule.

because -Os says it optimizes for size, the expectation is clear.
-O3 does not necessarily give better optimization than -O2.

> I agree with Dave Korn, I do not understand your objection.

I am objecting to the perceived benefits of the scheme and
the false dubious analogy with -O.

>
> I would understand an objection of the general kind that you
> prefer mnemonic names to numbers, but that ultimately is just
> that a preference, nothing more.

I would not be surprise if any contrary opinion to your preference
isn't a preference :-)

> You seem on the contrary to
> be trying to make a substantive argument against the digit
> scheme, but I can't understand it.

I am puzzled by this.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote:

> What is nonsensical there?
>
>> But they *are* ordinal.
>
> Now?  What is the order?

less warnings to more warnings, what could be more
ordered than that!

>>   It works just fine for -O,
>
> Exactly what happens with -O?  -On does not necessarily
> generate faster or better code when n is higher.

-On means more optimizations for higher n, simple enough?
>
> In fact, -Os is a perfect example of a short name that is NOT
> a number.

right, because -Os lies outside the more optimizations for
higher values rule.

I agree with Dave Korn, I do not understand your objection.

I would understand an objection of the general kind that you
prefer mnemonic names to numbers, but that ultimately is just
that a preference, nothing more. You seem on the contrary to
be trying to make a substantive argument against the digit
scheme, but I can't understand it.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>
>>>> People easily associates some ordering to numbers (usually
>>>> the greater the better or in this case the worse) which
>>>> creates another set of confusion.
>
>>>  What's the problem?  The greater the number, the more warnings you get.  Simple.
>>
>> Not necessarily.
>
>  Your argument makes no sense.

Do you think that assertion makes sens when no evidence is
provided to support it?

> You said that there was a problem because
> people will expect numbered -W options to be ordinal.

What is nonsensical there?

> But they *are* ordinal.

Now?  What is the order?

>  So people's expectations will be correct.  You haven't said anything about
> where the problem is yet, you've just asserted that there will be one without
> demonstration or evidence, so again I ask: What's the problem?

You said the greater the number the more warnings you get, but you did not
show that would happen, so you have not shown that would necessarily happen.
What is nonsensical there?

>
>  It works just fine for -O,

Exactly what happens with -O?  -On does not necessarily
generate faster or better code when n is higher.

In fact, -Os is a perfect example of a short name that is NOT
a number.

> users understand and are happy with that, why
> shouldn't it work just as well for -W?
>
>    cheers,
>      DaveK
>

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 15:55, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:

>>> People easily associates some ordering to numbers (usually
>>> the greater the better or in this case the worse) which
>>> creates another set of confusion.

>>  What's the problem?  The greater the number, the more warnings you get.  Simple.
> 
> Not necessarily.

  Your argument makes no sense.  You said that there was a problem because
people will expect numbered -W options to be ordinal.  But they *are* ordinal.
 So people's expectations will be correct.  You haven't said anything about
where the problem is yet, you've just asserted that there will be one without
demonstration or evidence, so again I ask: What's the problem?

  It works just fine for -O, users understand and are happy with that, why
shouldn't it work just as well for -W?

    cheers,
      DaveK

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar <dewar@adacore.com> wrote:
>>> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>>>
>>>>>> -W0: no warnings (equivalent to -w)
>>>>>> -W1: default
>>>>>> -W2: equivalent to the current -Wall
>>>>>> -W3: equivalent to the current -Wall -Wextra
>>>>>
>>>>>  I like this suggestion a lot.
>>>
>>> Me too!
>>>
>>> I also like short switches, but gcc mostly favors long
>>> hard-to-type not-necessarily-easy-to-remember switch
>>> names.
>>
>> People easily associates some ordering to numbers (usually
>> the greater the better or in this case the worse) which
>> creates another set of confusion.
>
>  What's the problem?  The greater the number, the more warnings you get.  Simple.

Not necessarily.

By contrast, -Wname suggest switch warning you could expect.
Note also that "short" does not need to be a number.

>
>>  Geodelization is great
>> for machines, hardly so as human interface.
>
>  I don't think the incompleteness theorem is remotely relevant here.

It is the process, not the end end result.

>
>    cheers,
>      DaveK
>
>

Re: RFC: -Wall by default

[Dave Korn]

On 12/04/2012 15:43, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar <dewar@adacore.com> wrote:
>> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>>
>>>>> -W0: no warnings (equivalent to -w)
>>>>> -W1: default
>>>>> -W2: equivalent to the current -Wall
>>>>> -W3: equivalent to the current -Wall -Wextra
>>>>
>>>>  I like this suggestion a lot.
>>
>> Me too!
>>
>> I also like short switches, but gcc mostly favors long
>> hard-to-type not-necessarily-easy-to-remember switch
>> names.
> 
> People easily associates some ordering to numbers (usually
> the greater the better or in this case the worse) which
> creates another set of confusion.

  What's the problem?  The greater the number, the more warnings you get.  Simple.

>  Geodelization is great
> for machines, hardly so as human interface.

  I don't think the incompleteness theorem is remotely relevant here.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>
>>>> -W0: no warnings (equivalent to -w)
>>>> -W1: default
>>>> -W2: equivalent to the current -Wall
>>>> -W3: equivalent to the current -Wall -Wextra
>>>
>>>
>>>  I like this suggestion a lot.
>
>
> Me too!
>
> I also like short switches, but gcc mostly favors long
> hard-to-type not-necessarily-easy-to-remember switch
> names.

People easily associates some ordering to numbers (usually
the greater the better or in this case the worse) which
creates another set of confusion.  Geodelization is great
for machines, hardly so as human interface.

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:

>>> -W0: no warnings (equivalent to -w)
>>> -W1: default
>>> -W2: equivalent to the current -Wall
>>> -W3: equivalent to the current -Wall -Wextra
>>
>>   I like this suggestion a lot.

Me too!

I also like short switches, but gcc mostly favors long
hard-to-type not-necessarily-easy-to-remember switch
names.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 5:23 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 11/04/2012 09:50, Vincent Lefevre wrote:
>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
>>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>>
>>>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>>>> means something quite specific for compilers, and the warning switch
>>>>> wouldn't have anything to do with standards conformance.
>>>> -Wdefault
>>>>
>>>> might be better
>>> except if people want warnings about "defaults" in C++11 (which can mean
>>> lot of things).
>>
>> How about a warning level?
>>
>> -W0: no warnings (equivalent to -w)
>> -W1: default
>> -W2: equivalent to the current -Wall
>> -W3: equivalent to the current -Wall -Wextra
>
>  I like this suggestion a lot.
>

me, very not. :-(

-- Gaby

Re: RFC: -Wall by default

[Diego Novillo]

On 4/12/12 6:23 AM, Dave Korn wrote:

>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>> How about a warning level?
>>
>> -W0: no warnings (equivalent to -w)
>> -W1: default
>> -W2: equivalent to the current -Wall
>> -W3: equivalent to the current -Wall -Wextra
>
>    I like this suggestion a lot.

Indeed.


Diego.

Re: RFC: -Wall by default

[Dave Korn]

On 11/04/2012 09:50, Vincent Lefevre wrote:
> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>
>>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>>> means something quite specific for compilers, and the warning switch
>>>> wouldn't have anything to do with standards conformance.
>>> -Wdefault
>>>
>>> might be better
>> except if people want warnings about "defaults" in C++11 (which can mean
>> lot of things).
> 
> How about a warning level?
> 
> -W0: no warnings (equivalent to -w)
> -W1: default
> -W2: equivalent to the current -Wall
> -W3: equivalent to the current -Wall -Wextra

  I like this suggestion a lot.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar <dewar@adacore.com> wrote:
> > On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
> >
> >> Maybe -Wstandard isn't the best name though, as "standard" usually
> >> means something quite specific for compilers, and the warning switch
> >> wouldn't have anything to do with standards conformance.
> >
> > -Wdefault
> >
> > might be better
> 
> except if people want warnings about "defaults" in C++11 (which can mean
> lot of things).

How about a warning level?

-W0: no warnings (equivalent to -w)
-W1: default
-W2: equivalent to the current -Wall
-W3: equivalent to the current -Wall -Wextra

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-08 18:56:27 +0100, Jonathan Wakely wrote:
> Anyway, GCC prints the option that controls a warning as part of the
> diagnostic, so it's trivial to find which options control the
> diagnostics that are annoying you.

And it's fine that using the -Wno-... form doesn't make the
compilation fail if the option is not supported (e.g. with older
GCC versions). It doesn't seem to be documented, though.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-10 14:48:05 +0100, Andrew Haley wrote:
> On 04/05/2012 12:30 PM, Vincent Lefevre wrote:
> > On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
> >> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> >>> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
> >>>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> >>>>> Really?  Such as what?
> >>>>
> >>>> Such as "I wrote a perfectly legal C program, and gcc spewed out
> >>>> a ton of messages."
> >>>
> >>> What's a "legal C program"?
> >>
> >> It's generally used to mean one that is fully defined by the
> >> specifications in effect, often some combination of POSIX and ISO C,
> >> with perhaps some vendor extensions.  Why do you ask?
> > 
> > Because: What if the specifications in effect say (as some vendor
> > extension) that some construct will generate some warning?
> 
> Interesting.  I had not considered that, but I have never seen such a
> specification.  Usually warnings are for things that are permitted by
> a specification, but not "good" in some way.  That's why warnings are
> usually optional, AFAIK; the program is well-defined, but has some
> properties that are, in the opinion of the compiler writer,
> undesirable.

There's also the case where the program is well-defined for some
specifications, but will have a different behavior with other
specifications, e.g. a newer standard (like C99 vs C89) or a
different one (like C++ vs C -- e.g. with MPFR, one allows it
to be built with a C++ compiler). In particular in the former
case, it's just C in both standards, but the concept of a
"legal C program" will vary (note that the broken[*] -std cannot
be used to tell GCC that the user wants to support both C89 and
C99).

[*] because it is not possible to distinguish between what GCC
supports and what GCC allows (there have already been discussions
about this).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 16:44:28 -0400, Robert Dewar wrote:
> On 4/5/2012 4:24 PM, Russ Allbery wrote:
> >Personally, as a matter of *style*, I eliminate such cases either by
> >initializing the variable or restructuring the function.  But this is very
> >much a question of style, not of correctness.
> 
> Indeed, and for me, when you are forced to do an initialization like
> this, it is mandatory to comment why you are initializing it, otherwise
> it obscures the code ("why is this being initialized, where is that
> value used?") and that ends up junky IMO. The Ada front end unfortunately
> has quite a few such commented junk initializations.

And moreover, perhaps in such a case, other compilers and/or future
GCC versions would give a warning because a value is set but not used.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sheds:  -Wcommon ?
>
> To use a variant of your own counterargument against -Wdefault:  "common"
> also has a special commonly (ahem :) used meaning, symbol binding and
> sections ;-)
>
>
> SCNR,
> Michael.

Make it -Wcommon-sense then.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sheds:  -Wcommon ?
>
> To use a variant of your own counterargument against -Wdefault:  "common"
> also has a special commonly (ahem :) used meaning, symbol binding and
> sections ;-)

Your are welcome. ;-)

I hope the notion of "defaults" in C++11 wasn't lost on anyone.

>
>
> SCNR,
> Michael.

Re: RFC: -Wall by default

[Miles Bader]

Andrew Haley <aph@redhat.com> writes:
> The argument is that we should enable the warnings by default because
> it makes gcc more competitive.  But that only makes gcc more
> competitive if enabling these kinds of warnings by default is an
> advantage.  However, we haven't established that -Wall by default is
> advantageous.

More warnings (if they're reasonable warning) enabled results in
better, less buggy, more portable, code for users.  That's surely an
advantage for users, and making users happy is good for gcc, yes?

[Moreover, by helping to prevent obscure bugs caused by bogus code, it
can help avoid people thinking that "the compiler's broken".]

-miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

Re: RFC: -Wall by default

[Andrew Haley]

On 04/05/2012 12:30 PM, Vincent Lefevre wrote:
> On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
>> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
>>> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
>>>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
>>>>> Really?  Such as what?
>>>>
>>>> Such as "I wrote a perfectly legal C program, and gcc spewed out
>>>> a ton of messages."
>>>
>>> What's a "legal C program"?
>>
>> It's generally used to mean one that is fully defined by the
>> specifications in effect, often some combination of POSIX and ISO C,
>> with perhaps some vendor extensions.  Why do you ask?
> 
> Because: What if the specifications in effect say (as some vendor
> extension) that some construct will generate some warning?

Interesting.  I had not considered that, but I have never seen such a
specification.  Usually warnings are for things that are permitted by
a specification, but not "good" in some way.  That's why warnings are
usually optional, AFAIK; the program is well-defined, but has some
properties that are, in the opinion of the compiler writer,
undesirable.

> Note that warnings in general are not forbidden by ISO C, so that
> there is nothing wrong as far as ISO C is concerned.

No, but ISO C only talks about diagnostics anyway: there is no real
distinction between warnings and errors.

Andrew.

Re: RFC: -Wall by default

[Andrew Haley]

On 04/05/2012 03:21 PM, Gabriel Dos Reis wrote:
> On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>>>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>>>>> but I very much like the idea of a gcc that does just what it's told;
>>>>> making -Wall the default is a big break with tradition.
>>>
>>> Sometimes, we have to be brave to challenge tradition.  The world around
>>> us is moving and we definitely want GCC to remain competitive.  It is
>>> hard to define what "it's told" means without tripping over.
>>
>> I'm finding it hard to understand why "-Wall by default" makes gcc more
>> competitive.
> 
> the competitors are enabling these kinds of warnings by default.

The argument is that we should enable the warnings by default because
it makes gcc more competitive.  But that only makes gcc more
competitive if enabling these kinds of warnings by default is an
advantage.  However, we haven't established that -Wall by default is
advantageous.

Surely this is the fallacy of circular reasoning: you're assuming your
conclusion.

> Furthermore, telling users that they just have to turn these simple
> switches -- when we are busy adding more at every release -- isn't
> convincing.

Why not?  You want Wall, so "-Wall".

Andrew.

Re: RFC: -Wall by default

[Michael Matz]

Hi,

On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:

> > To be honest, all of those sound fine to me...
> >
> > bike-sheddin',
> > -miles
> 
> at the risk of more bike sheds:  -Wcommon ?

To use a variant of your own counterargument against -Wdefault:  "common" 
also has a special commonly (ahem :) used meaning, symbol binding and 
sections ;-)


SCNR,
Michael.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 2:07 AM, Miles Bader <miles@gnu.org> wrote:
> 2012年4月10日15:26 Eric Botcazou <ebotcazou@adacore.com>:
>>> Something like -Wdefault-warnings is a reasonable choice, for the
>>> reasons already mentioned in this sub-thread.
>>
>> Purists will find that -Wdefault-warnings is redundant though, since -W is
>> supposed to mean "warning" already, e.g. it's -Wall and not -Wall-warnings.
>
> ("-Wnormal" ?)
>
> The name doesn't have to be perfect and utterly unambiguous, as it's
> rarely going to be used (and people cope with misleading names like
> -Wall :), and it's more important that it makes sense with "no-"
> prepended anyway...
>
> -Wno-standard
> -Wno-default
> -Wno-defaults
> -Wno-default-warnings
>
> To be honest, all of those sound fine to me...
>
> bike-sheddin',
> -miles

at the risk of more bike sheds:  -Wcommon ?

Re: RFC: -Wall by default

[Miles Bader]

2012年4月10日15:26 Eric Botcazou <ebotcazou@adacore.com>:
>> Something like -Wdefault-warnings is a reasonable choice, for the
>> reasons already mentioned in this sub-thread.
>
> Purists will find that -Wdefault-warnings is redundant though, since -W is
> supposed to mean "warning" already, e.g. it's -Wall and not -Wall-warnings.

("-Wnormal" ?)

The name doesn't have to be perfect and utterly unambiguous, as it's
rarely going to be used (and people cope with misleading names like
-Wall :), and it's more important that it makes sense with "no-"
prepended anyway...

-Wno-standard
-Wno-default
-Wno-defaults
-Wno-default-warnings

To be honest, all of those sound fine to me...

bike-sheddin',
-miles

-- 
Cat is power.  Cat is peace.

Re: RFC: -Wall by default

[Eric Botcazou]

> Something like -Wdefault-warnings is a reasonable choice, for the
> reasons already mentioned in this sub-thread.

Purists will find that -Wdefault-warnings is redundant though, since -W is 
supposed to mean "warning" already, e.g. it's -Wall and not -Wall-warnings.

-- 
Eric Botcazou

Re: RFC: -Wall by default

[James Cloos]

>>>> Maybe -Wstandard isn't the best name though, as "standard" usually...

AS> It doesn't have to be short: -Wdefault-warnings.

I haven't looked at all of the replies since I posted, and I *had*
forgotten about -Wextra (I can't even remember how many years it has
been since I last read that section of the manual), but adding a new
option to contain the default warnings fits well with my thesis.

Something like -Wdefault-warnings is a reasonable choice, for the
reasons already mentioned in this sub-thread.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: RFC: -Wall by default

[Andreas Schwab]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar <dewar@adacore.com> wrote:
>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>
>>> Maybe -Wstandard isn't the best name though, as "standard" usually
>>> means something quite specific for compilers, and the warning switch
>>> wouldn't have anything to do with standards conformance.
>>
>>
>> -Wdefault
>>
>> might be better
>
> except if people want warnings about "defaults" in C++11 (which can mean
> lot of things).

It doesn't have to be short: -Wdefault-warnings.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Mon, Apr 9, 2012 at 12:36 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> Maybe -Wstandard isn't the best name though, as "standard" usually
> means something quite specific for compilers, and the warning switch
> wouldn't have anything to do with standards conformance.

I agree.

I have been resisting to go there for fear of derailing the discussion, but I am
open to better suggestion.  -Wsanity? :-)

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>
>> Maybe -Wstandard isn't the best name though, as "standard" usually
>> means something quite specific for compilers, and the warning switch
>> wouldn't have anything to do with standards conformance.
>
>
> -Wdefault
>
> might be better

except if people want warnings about "defaults" in C++11 (which can mean
lot of things).

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

On 4/9/2012 1:36 PM, Jonathan Wakely wrote:

> Maybe -Wstandard isn't the best name though, as "standard" usually
> means something quite specific for compilers, and the warning switch
> wouldn't have anything to do with standards conformance.

-Wdefault

might be better

Re: RFC: -Wall by default

[Jonathan Wakely]

On 9 April 2012 18:29, Eric Botcazou wrote:
>> That would be my preferred solution -- by far.  But, my understanding
>> is that that would provoke a riot so I am willing to compromise by
>> introducing a new warning switch (even if I dislike that thought.)
>> Hopefully, it is it is going to be the default, most people would not have
>> to learn yet another GCC switch.
>
> Why to introduce a new switch then?  Just select a few -W switches and enable
> them by default, keeping in mind that -w will disable them in any cases.

-w prevents any warnings being printed at all, it couldn't be used to
turn off -Wstandard then selectively re-enable individual options,
e.g. with -Wno-standard -Wmain

Introducing a new switch would mean there's a single -Wno-standard
switch for those who want to restore the old default behaviour, so
they don't have to explicitly add -Wno-aaa -Wno-bbb -Wno-ccc etc.

Maybe -Wstandard isn't the best name though, as "standard" usually
means something quite specific for compilers, and the warning switch
wouldn't have anything to do with standards conformance.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/9/2012 1:29 PM, Eric Botcazou wrote:
>> That would be my preferred solution -- by far.  But, my understanding
>> is that that would provoke a riot so I am willing to compromise by
>> introducing a new warning switch (even if I dislike that thought.)
>> Hopefully, it is it is going to be the default, most people would not have
>> to learn yet another GCC switch.
>
> Why to introduce a new switch then?  Just select a few -W switches and enable
> them by default, keeping in mind that -w will disable them in any cases.

I think the idea is just to have an easy way to describe the relevant 
set of warnings, and a specific way (-Wno-standard) to go back to the
status quo.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/9/2012 1:29 PM, Gabriel Dos Reis wrote:

> We are in agreement.  I was just explaining to Gerald that his proposal
> would have been my first choice, but I am compromising by moving to
> your suggestion.  My complaint is the introduction of a new switch
> just to accomodate warnings that should not have been in -Wall.  But,
> I can live with that.

Well if the set of options is chosen right, -Wstandard is not a switch
that will be used, and equally -Wno-standard will not be often used,
so yes, it is an extra switch, but not one that has to be remembered.
>
>>
>>>
>>>>
>>>> Gerald
>>
>>

Re: RFC: -Wall by default

[Eric Botcazou]

> That would be my preferred solution -- by far.  But, my understanding
> is that that would provoke a riot so I am willing to compromise by
> introducing a new warning switch (even if I dislike that thought.)
> Hopefully, it is it is going to be the default, most people would not have
> to learn yet another GCC switch.

Why to introduce a new switch then?  Just select a few -W switches and enable 
them by default, keeping in mind that -w will disable them in any cases.

-- 
Eric Botcazou

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Mon, Apr 9, 2012 at 12:15 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer<gerald@pfeifer.com>
>>  wrote:
>>>
>>> On Sun, 8 Apr 2012, Robert Dewar wrote:
>>>>
>>>> Do you really want me to file hundreds of bug reports that are for
>>>> cases of uninitialized variables well known to everyone, and well
>>>> understood by everyone, and not easy to fix (or would have been
>>>> fixed long ago)?
>>>
>>>
>>> Perhaps we should move this class of warning from -Wall to -Wextra?
>>>
>>> (I'd prefer that over introducing yet another option -Wstandard.)
>>
>>
>> That would be my preferred solution -- by far.  But, my understanding
>> is that that would provoke a riot so I am willing to compromise by
>> introducing
>> a new warning switch (even if I dislike that thought.)
>> Hopefully, it is it is going to be the default, most people would not have
>> to learn yet another GCC switch.
>
>
> I would not like to see -Wall lose warnings that it has now, and I think
> others would find that a problme. -Wextra may be too much for that same
> group of people.
>
> We have certainly found it useful to have three general categories of
> warnings in GNAT
>
> a) the warnings that are on by default
> b) the warnings that are turned on by -gnatWa (similar to -Wall)
> c) all warnings (tunred on by -gnatw.e)

We are in agreement.  I was just explaining to Gerald that his proposal
would have been my first choice, but I am compromising by moving to
your suggestion.  My complaint is the introduction of a new switch
just to accomodate warnings that should not have been in -Wall.  But,
I can live with that.

>
>>
>>>
>>> Gerald
>
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote:
> On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer<gerald@pfeifer.com>  wrote:
>> On Sun, 8 Apr 2012, Robert Dewar wrote:
>>> Do you really want me to file hundreds of bug reports that are for
>>> cases of uninitialized variables well known to everyone, and well
>>> understood by everyone, and not easy to fix (or would have been
>>> fixed long ago)?
>>
>> Perhaps we should move this class of warning from -Wall to -Wextra?
>>
>> (I'd prefer that over introducing yet another option -Wstandard.)
>
> That would be my preferred solution -- by far.  But, my understanding
> is that that would provoke a riot so I am willing to compromise by introducing
> a new warning switch (even if I dislike that thought.)
> Hopefully, it is it is going to be the default, most people would not have
> to learn yet another GCC switch.

I would not like to see -Wall lose warnings that it has now, and I think
others would find that a problme. -Wextra may be too much for that same
group of people.

We have certainly found it useful to have three general categories of
warnings in GNAT

a) the warnings that are on by default
b) the warnings that are turned on by -gnatWa (similar to -Wall)
c) all warnings (tunred on by -gnatw.e)

>
>>
>> Gerald

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Sun, 8 Apr 2012, Robert Dewar wrote:
>> Do you really want me to file hundreds of bug reports that are for
>> cases of uninitialized variables well known to everyone, and well
>> understood by everyone, and not easy to fix (or would have been
>> fixed long ago)?
>
> Perhaps we should move this class of warning from -Wall to -Wextra?
>
> (I'd prefer that over introducing yet another option -Wstandard.)

That would be my preferred solution -- by far.  But, my understanding
is that that would provoke a riot so I am willing to compromise by introducing
a new warning switch (even if I dislike that thought.)
Hopefully, it is it is going to be the default, most people would not have
to learn yet another GCC switch.

>
> Gerald

RE: RFC: -Wall by default

[Paul_Koning]

I think removing an existing warning from -Wall would be a bad idea.

	paul

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Gerald Pfeifer
Sent: Monday, April 09, 2012 12:30 PM
To: Robert Dewar
Cc: Jonathan Wakely; James Cloos; gcc@gcc.gnu.org; Miles Bader; Gabriel Dos Reis; Ian Lance Taylor; Andrew Haley
Subject: Re: RFC: -Wall by default

On Sun, 8 Apr 2012, Robert Dewar wrote:
> Do you really want me to file hundreds of bug reports that are for 
> cases of uninitialized variables well known to everyone, and well 
> understood by everyone, and not easy to fix (or would have been fixed 
> long ago)?

Perhaps we should move this class of warning from -Wall to -Wextra?

(I'd prefer that over introducing yet another option -Wstandard.)

Gerald

Re: RFC: -Wall by default

[Gerald Pfeifer]

On Sun, 8 Apr 2012, Robert Dewar wrote:
> Do you really want me to file hundreds of bug reports that are for
> cases of uninitialized variables well known to everyone, and well
> understood by everyone, and not easy to fix (or would have been
> fixed long ago)?

Perhaps we should move this class of warning from -Wall to -Wextra?

(I'd prefer that over introducing yet another option -Wstandard.)

Gerald

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 4:59 PM, Gabriel Dos Reis wrote:

> no, -Wstandard wasn't in my original proposal.  It is the name suggested
> by Miles for the list I gave Arnaud upon request.

I know that, I can read -:)

I am just saying I think this issue still needs discussion (and you
were complaining about continuing "arguing", to me btw discussion
is American for argument :-))

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 3:29 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>>
>>> On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
>>
>>
>>>> But I'd be just as happy with a -Wstandard (by any name) enabled by
>>>> default as I would be with -Wall on by default. Only enabling warnings
>>>> with very little chance of false positives would avoid most of the
>>>> negative consequences.
>>>
>>>
>>>
>>> Yes, I think that is the case! That's certainly the philosophy we
>>> follow in GNAT.
>>
>>
>> and I think that is all this is about.  I am puzzled we are still
>> arguing...
>
>
> We are discussing. And note that the idea of -Wstandard was certainly
> not in your original proposal (note the [by now confusing] subject
> of this thread!)

no, -Wstandard wasn't in my original proposal.  It is the name suggested
by Miles for the list I gave Arnaud upon request.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 3:28 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:
>
>> I think I agree with this.  I suspect the only difference might be that
>> I do not believe the fix is necessarily to turn them off.
>
>
> Well there are three possibilities
>
> a) fix the false positives, at the possible expense of introducing
> new false negatives, but most of these warnings are very far from
> sound anyway (they do not guarantee that code not raising the warning
> is free from the problem involved).
>
> b) remove from -Wstandard
>
> c) leave in -Wstandard and live with the false positives
>
> I am saying I prefer these alternatives in the order given above.
> I suspect you agree with this ordering?

Yes.

>
> I use -Wstandard here just as a label for whatever gets turned
> on by default if a change is made. Whether the new switch with
> this name is introduced is an orthogonal issue.
>
>>
>>>  (certainly not an attitude that is
>>> taken with -Wall, if I am wrong, I have hundreds of bugs to
>>> report :-)) Yes, occasionally you get a case that you end up
>>> considering SO obscure that you violate this rule, but it is
>>> rare.
>>
>>
>> -Wall, despite the name, does not turn on all warnings.
>
>
> Yes, I know, what's that got to do with the comment above
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
> On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
>
>>> But I'd be just as happy with a -Wstandard (by any name) enabled by
>>> default as I would be with -Wall on by default. Only enabling warnings
>>> with very little chance of false positives would avoid most of the
>>> negative consequences.
>>
>>
>> Yes, I think that is the case! That's certainly the philosophy we
>> follow in GNAT.
>
> and I think that is all this is about.  I am puzzled we are still arguing...

We are discussing. And note that the idea of -Wstandard was certainly
not in your original proposal (note the [by now confusing] subject
of this thread!)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 4:25 PM, Gabriel Dos Reis wrote:
> On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
>>
>>> Again, that also applies when people use -Wall today: a false positive
>>> is unwanted even if you use -Wall, and those false positives are bugs
>>> and so having them in bugzilla is good.
>>
>>
>> Do you really want me to file hundreds of bug reports that are for
>> cases of uninitialized variables well known to everyone,
>
> Yes, unless thy are duplicates.

I think you know these *ARE* duplicates because everyone using
-Wall with gcc encounters them frequently!
>
>>   and well
>> understood by everyone, and not easy to fix (or would have been
>> fixed long ago)?

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:

> I think I agree with this.  I suspect the only difference might be that
> I do not believe the fix is necessarily to turn them off.

Well there are three possibilities

a) fix the false positives, at the possible expense of introducing
new false negatives, but most of these warnings are very far from
sound anyway (they do not guarantee that code not raising the warning
is free from the problem involved).

b) remove from -Wstandard

c) leave in -Wstandard and live with the false positives

I am saying I prefer these alternatives in the order given above.
I suspect you agree with this ordering?

I use -Wstandard here just as a label for whatever gets turned
on by default if a change is made. Whether the new switch with
this name is introduced is an orthogonal issue.
>
>>   (certainly not an attitude that is
>> taken with -Wall, if I am wrong, I have hundreds of bugs to
>> report :-)) Yes, occasionally you get a case that you end up
>> considering SO obscure that you violate this rule, but it is
>> rare.
>
> -Wall, despite the name, does not turn on all warnings.

Yes, I know, what's that got to do with the comment above

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 4:02 PM, Jonathan Wakely wrote:

>> But I'd be just as happy with a -Wstandard (by any name) enabled by
>> default as I would be with -Wall on by default. Only enabling warnings
>> with very little chance of false positives would avoid most of the
>> negative consequences.
>
>
> Yes, I think that is the case! That's certainly the philosophy we
> follow in GNAT.

and I think that is all this is about.  I am puzzled we are still arguing...

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
>
>> Again, that also applies when people use -Wall today: a false positive
>> is unwanted even if you use -Wall, and those false positives are bugs
>> and so having them in bugzilla is good.
>
>
> Do you really want me to file hundreds of bug reports that are for
> cases of uninitialized variables well known to everyone,

Yes, unless thy are duplicates.

>  and well
> understood by everyone, and not easy to fix (or would have been
> fixed long ago)?

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 2:53 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar<dewar@adacore.com>  wrote:
>>>
>>> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>>>
>>>>
>>>>  The people who don't want -Wall (or
>>>> -Wstandard) enabled are likely to be the ones who know how to use
>>>> -Wno-all or whatever to get what they want.
>>>
>>>
>>>
>>> I see no evidence that supports that guess. On the contrary, I
>>> would guess that if -Wall is set by default,
>>
>>
>> so your evidence to the contrary is a guess ;-p
>
>
> Yes, of course, though based to some extent on our experience
> with warnings that are enabled by default in GNAT, we often
> get newbie questions that complain about these warnings, it is
> somewhat inevitable, that if you have people who do not know the
> language, they will find some quite legitimate warnings puzzling,
> especially if they are false positives (we really try VERY hard
> to avoid false positives in the default set of warnings .. to me
> the trouble with -Wall is that it generates lots of false positives.

and you do not want to grant the benefit of experience to those of
us handling diagnostics requests and also based on what other
implementations are doing?

> Now a -Wstandard that is crafted with a different design goal than
> -Wall (avoid false positives at all costs) would be quite a different
> matter, and that is why I have supported this approach if anything
> at all is done.

Note at the exception of -Wunused (which is disputable) and
-Wuninitialized, -Wstandard is essentially -Wall.

>
> Basically in GNAT we regard it as a bug to work on if a default
> warning is a false positive

I think I agree with this.  I suspect the only difference might be that
I do not believe the fix is necessarily to turn them off.

>  (certainly not an attitude that is
> taken with -Wall, if I am wrong, I have hundreds of bugs to
> report :-)) Yes, occasionally you get a case that you end up
> considering SO obscure that you violate this rule, but it is
> rare.

-Wall, despite the name, does not turn on all warnings.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
> No, because those are already in bugzilla, and there's a whole wiki
> page about improving that particular warning.

Yes, I know, and that page is to me good justification for NOT including
this warning in the set that is on by default.
>
> But I'd be just as happy with a -Wstandard (by any name) enabled by
> default as I would be with -Wall on by default. Only enabling warnings
> with very little chance of false positives would avoid most of the
> negative consequences.

Yes, I think that is the case! That's certainly the philosophy we
follow in GNAT.

One debatable issue is the following kind of warnings:

>      1. procedure k is
>      2.    x : integer;
>            |
>         >>> warning: variable "x" is assigned but never read
>
>      3. begin
>      4.    x := 2;
>            |
>         >>> warning: useless assignment to "x", value never referenced
>
>      5. end;

These (not on by default in GNAT by the way) are examples of warnings
that most certainly are NOT false positives, but they are examples of
warnings about perfectly valid code.

That's quite different from a warning like:

>      1. function l (m : integer) return Boolean is
>      2. begin
>      3.    if m > 10 then
>            |
>         >>> warning: "return" statement missing following this statement
>         >>> warning: Program_Error may be raised at run time
>
>      4.       return False;
>      5.    end if;
>      6. end;

Where you definitely have a real bug in the code, and the code is
not in any reasonable sense valid (yes, the RM does not make this
code illegal, but that's just because it would be too much effort).

An interesting third category is:

>      1. procedure Norm is
>      2. begin
>      3.    pragma Dummy_Body;
>                   |
>         >>> warning: unrecognized pragma "Dummy_Body"
>
>      4.    null;
>      5. end;

Here the standard mandates ignoring unrecognized pragmas, so the
compiler is doing the right thing, and in one sense the above is
a false positive, since there is nothing wrong. However, in this
case we have the following (highly peculiar) statement in the RM

> 13  The implementation shall give a warning message for an unrecognized pragma
> name.

(why highly peculiar, becuase in a formal definition of this
kind the notion of "warning message" is totally undefined and
pretty much undefinable.)

Re: RFC: -Wall by default

[Jonathan Wakely]

On 8 April 2012 20:54, Robert Dewar wrote:
> On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
>
>> Again, that also applies when people use -Wall today: a false positive
>> is unwanted even if you use -Wall, and those false positives are bugs
>> and so having them in bugzilla is good.
>
>
> Do you really want me to file hundreds of bug reports that are for
> cases of uninitialized variables well known to everyone, and well
> understood by everyone, and not easy to fix (or would have been
> fixed long ago)?

No, because those are already in bugzilla, and there's a whole wiki
page about improving that particular warning.

But I'd be just as happy with a -Wstandard (by any name) enabled by
default as I would be with -Wall on by default. Only enabling warnings
with very little chance of false positives would avoid most of the
negative consequences.

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 3:37 PM, Jonathan Wakely wrote:

> Again, that also applies when people use -Wall today: a false positive
> is unwanted even if you use -Wall, and those false positives are bugs
> and so having them in bugzilla is good.

Do you really want me to file hundreds of bug reports that are for
cases of uninitialized variables well known to everyone, and well
understood by everyone, and not easy to fix (or would have been
fixed long ago)?

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
> On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>>
>>>   The people who don't want -Wall (or
>>> -Wstandard) enabled are likely to be the ones who know how to use
>>> -Wno-all or whatever to get what they want.
>>
>>
>> I see no evidence that supports that guess. On the contrary, I
>> would guess that if -Wall is set by default,
>
> so your evidence to the contrary is a guess ;-p

Yes, of course, though based to some extent on our experience
with warnings that are enabled by default in GNAT, we often
get newbie questions that complain about these warnings, it is
somewhat inevitable, that if you have people who do not know the
language, they will find some quite legitimate warnings puzzling,
especially if they are false positives (we really try VERY hard
to avoid false positives in the default set of warnings .. to me
the trouble with -Wall is that it generates lots of false positives.

Now a -Wstandard that is crafted with a different design goal than
-Wall (avoid false positives at all costs) would be quite a different
matter, and that is why I have supported this approach if anything
at all is done.

Basically in GNAT we regard it as a bug to work on if a default
warning is a false positive (certainly not an attitude that is
taken with -Wall, if I am wrong, I have hundreds of bugs to
report :-)) Yes, occasionally you get a case that you end up
considering SO obscure that you violate this rule, but it is
rare.

Re: RFC: -Wall by default

[Jonathan Wakely]

On 8 April 2012 19:51, Robert Dewar wrote:
> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>
>>  The people who don't want -Wall (or
>> -Wstandard) enabled are likely to be the ones who know how to use
>> -Wno-all or whatever to get what they want.
>
>
> I see no evidence that supports that guess. On the contrary, I
> would guess that if -Wall is set by default, you will get lots
> of (probably invalid) complaints of the sort "why is gcc complaining
> at perfectly correct code", and of course in some cases those will
> be false positives, so they will be valid complaints.

Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so having them in bugzilla is good.  For the cases where the
warning is valid we're doing the user a service by showing or teaching
them that their code is problematic. Having to triage and close
invalid bug reports from those users may be a bit tedious but still
does them a service by encouraging them to improve their code.  So
there are positive aspects of both valid and invalid reports caused by
enabling -Wall

PR 51270 is just one example I happened across today where the
reporter says "constness violation is accepted without any warning"
then shows that g++ was being invoked without any warning options.  At
least some users expect to get warnings without having to request them
explicitly.  GCC doesn't tell you to use -Wall to get diagnostics that
weren't printed but could have been, whereas when a diagnostic is
issued the relevant option is shown. The option to suppress an
unwanted warning is arguably more discoverable than the option to
enable a warning that isn't being given.  (I say arguably, because you
have to know to say -Wno-xxx to suppress the warnings that print
-Wxxx)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>
>>  The people who don't want -Wall (or
>> -Wstandard) enabled are likely to be the ones who know how to use
>> -Wno-all or whatever to get what they want.
>
>
> I see no evidence that supports that guess. On the contrary, I
> would guess that if -Wall is set by default,

so your evidence to the contrary is a guess ;-p

> you will get lots
> of (probably invalid) complaints of the sort "why is gcc complaining
> at perfectly correct code", and of course in some cases those will
> be false positives, so they will be valid complaints.
>

Re: RFC: -Wall by default

[Robert Dewar]

On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>  The people who don't want -Wall (or
> -Wstandard) enabled are likely to be the ones who know how to use
> -Wno-all or whatever to get what they want.

I see no evidence that supports that guess. On the contrary, I
would guess that if -Wall is set by default, you will get lots
of (probably invalid) complaints of the sort "why is gcc complaining
at perfectly correct code", and of course in some cases those will
be false positives, so they will be valid complaints.

Re: RFC: -Wall by default

[Jonathan Wakely]

On 8 April 2012 16:16, James Cloos wrote:
>
> Sure.  Making a few more of the -W flags on by default may be OK,
> depending on the chosen list.  It is the idea of turing all possible
> warning options on by default which is unreasonable.

Noone's suggested doing that. As Gaby said, -Wall doesn't turn on all warnings.

> Defaulting to -Wall also fails as a user interface design.  -Wall is
> a nice, short, sweet, easy to type optiong which one readily can add
> at any time.

So is -Wno-all

>  Forcing one to have to find all of the -Wno-... options
> to avoid unwanted annoyances,

That applies even if -Wall isn't on by default.  People who use -Wall
(which means lots of people) still have to use -Wno-xxx to disable the
warnings they don't want. Making -Wall on by default doesn't change
that.

Anyway, GCC prints the option that controls a warning as part of the
diagnostic, so it's trivial to find which options control the
diagnostics that are annoying you.

> or to the -Wno-all and a set of -Ws
> which one does want is far more cumbersome.

Why is using -Wno-all -Wfoo -Wbar "far more cumbersome" than what you
have to do to get the same effect today?  i.e. -Wfoo -Wbar

Those points apply equally to what we have today and so aren't really
relevant to whether -Wall should be on by default or not.

> And what if new warning are added.  Does anyone really want them *all*
> on by default as soon as the code lands?

That argument also applies equally to -Wall as it is today,
maintainers need to decide if new warnings should be included in -Wall
or not, as that affects everyone who uses -Wall (which is a large
number of users.)  That wouldn't be any different if -Wall was enabled
by default.

> If there are some useful warning not already on by default which tend
> not to false-positive and provide useful, beneficial information when
> triggered, then it is reasonable to look into starting to default-enable
> them.

That's not far from what has been proposed (although -Wall currently
contains some warnings that don't fit into that category, so maybe a
-Wstandard set would be useful.

>  Turning *all* of them on willy-nilly is not.

Noone's suggesting that.

FWIW we do sometimes have to close invalid bugzilla reports that
complain about no warning when the user simply failed to use -Wall, or
because the code is clearly wrong and they would have been told so if
they'd just used -Wall.  That does imply that people who don't know
what they're doing (and so might benefit most from enabling warnings)
aren't aware of -Wall.  The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they want.

Re: RFC: -Wall by default

[Dave Korn]

On 07/04/2012 23:58, Gabriel Dos Reis wrote:
> On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote:

>>> -Wunused-function
>>> -Wunused-label
>>> -Wunused-value
>>> -Wunused-variable

>>  IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
>> -Wall by default.  The rest seem pretty reasonable defaults to me.
> 
> Even if we do not turn on -Wall by default, do you think we should
> have -Wunused in -Wall?

  I think they're of limited use, bearing in mind typical C usage patterns,
but unless we were upheaving everything anyway, I can't see much reason to
change the status quo.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sun, Apr 8, 2012 at 10:16 AM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MB" == Miles Bader <miles@gnu.org> writes:
>
> MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which
> MB> is a little more conservative, "-Wstandard" or something...]
>
> Sure.  Making a few more of the -W flags on by default may be OK,
> depending on the chosen list.  It is the idea of turing all possible
> warning options on by default which is unreasonable.

You might want to get your facts straight: -Wall does not turn
on all possible warning options.

-- Gaby

Re: RFC: -Wall by default

[James Cloos]

>>>>> "MB" == Miles Bader <miles@gnu.org> writes:

MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which
MB> is a little more conservative, "-Wstandard" or something...]

Sure.  Making a few more of the -W flags on by default may be OK,
depending on the chosen list.  It is the idea of turing all possible
warning options on by default which is unreasonable.

Defaulting to -Wall also fails as a user interface design.  -Wall is
a nice, short, sweet, easy to type optiong which one readily can add
at any time.  Forcing one to have to find all of the -Wno-... options
to avoid unwanted annoyances, or to the -Wno-all and a set of -Ws
which one does want is far more cumbersome.

And what if new warning are added.  Does anyone really want them *all*
on by default as soon as the code lands?

If there are some useful warning not already on by default which tend
not to false-positive and provide useful, beneficial information when
triggered, then it is reasonable to look into starting to default-enable
them.  Turning *all* of them on willy-nilly is not.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: RFC: -Wall by default

[Robert Dewar]

On 4/7/2012 6:57 PM, Miles Bader wrote:
> Dave Korn<dave.korn.cygwin@gmail.com>  writes:
>>    IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
>> -Wall by default.  The rest seem pretty reasonable defaults to me.
>
> How about instead adding new "-Wstandard", which will be on by default,
> and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for
> people that currently use -Wall).

I think that's a good idea, then if -Wstandard generates complaints that
can be fixed by rethinking inclusion of some options, that's easily
fixed.
>
> -miles
>

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sat, Apr 7, 2012 at 5:57 PM, Miles Bader <miles@gnu.org> wrote:
> Dave Korn <dave.korn.cygwin@gmail.com> writes:
>>   IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
>> -Wall by default.  The rest seem pretty reasonable defaults to me.
>
> How about instead adding new "-Wstandard", which will be on by default,
> and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for
> people that currently use -Wall).

In the end, a new option might probably be a good
compromise even if I dislike the proliferation of options.  Thanks,

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 05/04/2012 10:46, Gabriel Dos Reis wrote:
>> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>
>>> Btw, it would be more reasonable to enable a subset of warnings that
>>> we enable at -Wall by default.
>>
>> Which ones for example?
>>
>> Here is a (partial) list:
>
>  Your list seems a bit short, here's what today's trunk build says for -Wall:

Thank you Dave for the correction.

>
>> -Waddress
>> -Warray-bounds (only with `-O2')
>> -Wc++11-compat
>> -Wchar-subscripts
>> -Wenum-compare (in C/Objc; this is on by default in C++)
>> -Wimplicit-int (C and Objective-C only)
>> -Wimplicit-function-declaration (C and Objective-C only)
>> -Wcomment
>> -Wformat
>> -Wmain (only for C/ObjC and unless `-ffreestanding')
>> -Wmaybe-uninitialized
>> -Wmissing-braces
>> -Wnonnull
>> -Wparentheses
>> -Wpointer-sign
>> -Wreorder
>> -Wreturn-type
>> -Wsequence-point
>> -Wsign-compare (only in C++)
>> -Wstrict-aliasing
>> -Wstrict-overflow=1
>> -Wswitch
>> -Wtrigraphs
>> -Wuninitialized
>> -Wunknown-pragmas
>> -Wunused-function
>> -Wunused-label
>> -Wunused-value
>> -Wunused-variable
>> -Wvolatile-register-var
>
>  IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
> -Wall by default.  The rest seem pretty reasonable defaults to me.

Even if we do not turn on -Wall by default, do you think we should
have -Wunused in -Wall?

-- Gaby

Re: RFC: -Wall by default

[Miles Bader]

Dave Korn <dave.korn.cygwin@gmail.com> writes:
>   IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
> -Wall by default.  The rest seem pretty reasonable defaults to me.

How about instead adding new "-Wstandard", which will be on by default,
and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for
people that currently use -Wall).

-miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that
there can't be a god.  He only has to be someone who believes that the
evidence on the God question is at a similar level to the evidence on
the werewolf question."  [John McCarthy]

Re: RFC: -Wall by default

[Dave Korn]

On 05/04/2012 10:46, Gabriel Dos Reis wrote:
> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> 
>> Btw, it would be more reasonable to enable a subset of warnings that
>> we enable at -Wall by default.
> 
> Which ones for example?
> 
> Here is a (partial) list:

  Your list seems a bit short, here's what today's trunk build says for -Wall:

> -Waddress
> -Warray-bounds (only with `-O2')
> -Wc++11-compat
> -Wchar-subscripts
> -Wenum-compare (in C/Objc; this is on by default in C++)
> -Wimplicit-int (C and Objective-C only)
> -Wimplicit-function-declaration (C and Objective-C only)
> -Wcomment
> -Wformat
> -Wmain (only for C/ObjC and unless `-ffreestanding')
> -Wmaybe-uninitialized
> -Wmissing-braces
> -Wnonnull
> -Wparentheses
> -Wpointer-sign
> -Wreorder
> -Wreturn-type
> -Wsequence-point
> -Wsign-compare (only in C++)
> -Wstrict-aliasing
> -Wstrict-overflow=1
> -Wswitch
> -Wtrigraphs
> -Wuninitialized
> -Wunknown-pragmas
> -Wunused-function
> -Wunused-label
> -Wunused-value
> -Wunused-variable
> -Wvolatile-register-var

  IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
-Wall by default.  The rest seem pretty reasonable defaults to me.

    cheers,
      DaveK

Re: RFC: -Wall by default

[Miles Bader]

James Cloos <cloos@jhcloos.com> writes:
> GDR> Exactly.  Our bugzilla databases has lot of requests in this spirit.
>
> If that is so, then defaulting to -Wall will just generate even more
> requests to turn that off.

You may well imagine.  However, it isn't known.  Turning it on by
default, at least for a while is one way to replace such imagination
with actual data...

[Or, perhaps, not "-Wall" perse, but maybe a new option which is a
little more conservative, "-Wstandard" or something...]

-miles

-- 
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Sat, Apr 7, 2012 at 4:46 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "GDR" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> GDR> Exactly.  Our bugzilla databases has lot of requests in this spirit.
>
> If that is so, then defaulting to -Wall will just generate even more
> requests to turn that off.
>
> I find it hard to image that anyone who does any significant amount of
> compiling would fail to have their own CFLAGS (et al) with the options
> which they prefer.

If all GCC users were forced to use the same development environment,
that would be a plausible proposition that does not necessarily draw on
limited imagination.

>
> Forcing -Wall for those who did not ask for it is <...words.escape...>.

Thanks for your thoughtful opinion and contributions.

-- Gaby

Re: RFC: -Wall by default

[James Cloos]

>>>>> "GDR" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

GDR> Exactly.  Our bugzilla databases has lot of requests in this spirit.

If that is so, then defaulting to -Wall will just generate even more
requests to turn that off.

I find it hard to image that anyone who does any significant amount of
compiling would fail to have their own CFLAGS (et al) with the options
which they prefer.

Forcing -Wall for those who did not ask for it is <...words.escape...>.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 4:24 PM, Russ Allbery wrote:
> Gabriel Dos Reis<gdr@integrable-solutions.net>  writes:
>
>> If it is the non-expert that would be caught in code so non-obvious that
>> -Wuninitialized would trip into false positives, then it is highly
>> likely that the code might in fact contain an error.
>
> I wish this were the case, but alas I continue to see fairly trivial false
> positives from -Wuninitialized.  Usually cases where the initialization
> and the use are both protected by equivalent conditionals at different
> places in the function.

Yes, and often it is not so easy for the compiler to see that the
conditionals are always the same
>
> Personally, as a matter of *style*, I eliminate such cases either by
> initializing the variable or restructuring the function.  But this is very
> much a question of style, not of correctness.

Indeed, and for me, when you are forced to do an initialization like
this, it is mandatory to comment why you are initializing it, otherwise
it obscures the code ("why is this being initialized, where is that
value used?") and that ends up junky IMO. The Ada front end 
unfortunately has quite a few such commented junk initializations.
>

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:24 PM, Russ Allbery <rra@stanford.edu> wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
>> If it is the non-expert that would be caught in code so non-obvious that
>> -Wuninitialized would trip into false positives, then it is highly
>> likely that the code might in fact contain an error.
>
> I wish this were the case, but alas I continue to see fairly trivial false
> positives from -Wuninitialized.  Usually cases where the initialization
> and the use are both protected by equivalent conditionals at different
> places in the function.
>
> Personally, as a matter of *style*, I eliminate such cases either by
> initializing the variable or restructuring the function.  But this is very
> much a question of style, not of correctness.

-Wuninitialized wasn't on the list I sent Arnaud.

(We were just arguing with different point of view on something
we appeared to agree on.)

-- Gaby

Re: RFC: -Wall by default

[Russ Allbery]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> If it is the non-expert that would be caught in code so non-obvious that
> -Wuninitialized would trip into false positives, then it is highly
> likely that the code might in fact contain an error.

I wish this were the case, but alas I continue to see fairly trivial false
positives from -Wuninitialized.  Usually cases where the initialization
and the use are both protected by equivalent conditionals at different
places in the function.

Personally, as a matter of *style*, I eliminate such cases either by
initializing the variable or restructuring the function.  But this is very
much a question of style, not of correctness.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley <aph@redhat.com> wrote:
> On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>>> > but I very much like the idea of a gcc that does just what it's told;
>>> > making -Wall the default is a big break with tradition.
>> Sometimes, we have to be brave to challenge tradition.  The world around
>> us is moving and we definitely want GCC to remain competitive.  It is
>> hard to define what "it's told" means without tripping over.
>
> I'm finding it hard to understand why "-Wall by default" makes gcc more
> competitive.

the competitors are enabling these kinds of warnings by default.  Furthermore,
telling users that they just have to turn these simple switches -- when we are
busy adding more at every release -- isn't convincing.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:29 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> Well, if you write code so obvious that -Wuninitialized is annoying then:
>
> No, the code is certainly not obvious, and improving -Wuninitialized although
> a nice goal is likely to require lots of effort, likely at the expense of
> removing some useful warnings.
>
>> either the implementation of -Wuninitialized should be improved, or as you
>
> You can't have it both ways: either -Wuninitialized is indeed improved to the
> point where it generates almost no false positives, and then enabling it
> by default should be considered/done; or -Wuninitialized does generate
> false positives and enabling it by default is likely not a good idea.

*I* do not think that the false positives of -Wuninitialized are so frequent
that it can't or should not be enabled by default; you are making that argument.
And I am saying *if* you what you say is true, then... Note the conditional.


>
> Same for -Wmaybe-uninitialized, also part of -Wall.
>
>> are so expert that you can add -Wno-uninitialized.  I think the argument
>> cuts both ways.
>
> Who said anything about being "so expert"? IMO that's precisely non
> experts who will get the most annoyed here, because they may not understand
> why the warning is generated, nor how to disable it.

If it is the non-expert that would be caught in code so non-obvious that
-Wuninitialized would trip into false positives, then it is highly likely
that the code might in fact contain an error.

> And IMO, a discussion about a "default" is certainly NOT about experts,

Full agreed.

> it's precisely a discussion about what would be the best default for most
> people (and most people are not experts).

agreed.  I don't see why we are arguing :-)

-- Gaby

Re: RFC: -Wall by default

[Jonathan Wakely]

On 5 April 2012 11:16, Arnaud Charlet wrote:
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code),

-Wstrict-aliasing is only active when -fstrict-aliasing is on, and if
that's on the warning definitely should be, since it indicates code
that may well misbehave, "legacy" or not.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 8:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 5 April 2012 11:03, Gabriel Dos Reis wrote:
>>>
>>> Note that some of the above depend on optimization flag settings
>>> (and optimization happening).  Those are not good candidates - I think
>>> good candidates are those that would still be fully operational with
>>> -fsyntax-only.
>>
>> I am not sure -fsyntax-only is a good criteria.
>> -fsyntax-only limits the amount of work that the compiler does in terms
>> of code generation, but it should be orthogonal to diagnostic issues.
>
> I don't think this is what you meant, but FWIW -fsyntax-only prevents
> (at least some) template instantiation for C++, which means lots of
> diagnostics are suppressed when using it.

Yes, thanks!

-- Gaby

Re: RFC: -Wall by default

[Jonathan Wakely]

On 5 April 2012 11:03, Gabriel Dos Reis wrote:
>>
>> Note that some of the above depend on optimization flag settings
>> (and optimization happening).  Those are not good candidates - I think
>> good candidates are those that would still be fully operational with
>> -fsyntax-only.
>
> I am not sure -fsyntax-only is a good criteria.
> -fsyntax-only limits the amount of work that the compiler does in terms
> of code generation, but it should be orthogonal to diagnostic issues.

I don't think this is what you meant, but FWIW -fsyntax-only prevents
(at least some) template instantiation for C++, which means lots of
diagnostics are suppressed when using it.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> > On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
> >> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> >>> Really?  Such as what?
> >>
> >> Such as "I wrote a perfectly legal C program, and gcc spewed out
> >> a ton of messages."
> > 
> > What's a "legal C program"?
> 
> It's generally used to mean one that is fully defined by the
> specifications in effect, often some combination of POSIX and ISO C,
> with perhaps some vendor extensions.  Why do you ask?

Because: What if the specifications in effect say (as some vendor
extension) that some construct will generate some warning?

Note that warnings in general are not forbidden by ISO C, so that
there is nothing wrong as far as ISO C is concerned.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 10:48:29 +0100, Pedro Alves wrote:
> On 04/05/2012 10:39 AM, Richard Guenther wrote:
> 
> ... [-Wall + -Werror] ...
> 
> > Btw, it would be more reasonable to enable a subset of warnings that
> > we enable at -Wall by default.  Notably those that if they were not
> > false positives, would lead to undefined behavior at runtime.  Specifically
> > I don't think we should warn about unused static functions or variables
> > by default.
> 
> Yes, I would agree more with something like that.

Ditto. I sometimes get such warnings just because of the use of the
preprocessor. However taking the preprocessor into account would
mean that some useful warnings (perhaps even with currently default
ones, but I'm not sure because I always use -Wall) could not be
included. The best solution is sometimes to modify the source. For
instance, I had to do the following change (not sure whether this
is the best way) in MPFR a few days ago:

Index: src/const_euler.c
===================================================================
--- src/const_euler.c   (revision 8123)
+++ src/const_euler.c   (revision 8124)
@@ -118,7 +118,7 @@
       int inex;
       MPFR_BLOCK_DECL (flags);
 
-      MPFR_BLOCK (flags, inex = mpfr_get_z (P, n, MPFR_RNDN));
+      MPFR_BLOCK (flags, MPFR_DBGRES (inex = mpfr_get_z (P, n, MPFR_RNDN)));
       MPFR_ASSERTD (inex == 0 && ! MPFR_ERANGEFLAG (flags));
       if (a > 1)
         mpz_mul_si (P, P, 1 - (long) a);
Index: src/mpfr-impl.h
===================================================================
--- src/mpfr-impl.h     (revision 8123)
+++ src/mpfr-impl.h     (revision 8124)
@@ -388,12 +388,18 @@
 #define MPFR_ASSERTN(expr)  \
    ((void) ((MPFR_UNLIKELY(expr)) || MPFR_UNLIKELY( (ASSERT_FAIL(expr),0) )))
 
-/* MPFR_ASSERTD(expr): assertions that should be checked when testing */
+/* MPFR_ASSERTD(expr): assertions that should be checked when testing.
+   MPFR_DBGRES(assignment): to be used when the result is tested only
+     in an MPFR_ASSERTD expression (in order to avoid a warning, e.g.
+     with GCC's -Wunused-but-set-variable, in non-debug mode).
+ */
 #ifdef WANT_ASSERT
 # define MPFR_EXP_CHECK 1
 # define MPFR_ASSERTD(expr)  MPFR_ASSERTN (expr)
+# define MPFR_DBGRES(A)      (A)
 #else
 # define MPFR_ASSERTD(expr)  ((void) 0)
+# define MPFR_DBGRES(A)      ((void) (A))
 #endif
 
 /* Code to deal with impossible

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Andrew Haley]

On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
>>> Really?  Such as what?
>>
>> Such as "I wrote a perfectly legal C program, and gcc spewed out
>> a ton of messages."
> 
> What's a "legal C program"?

It's generally used to mean one that is fully defined by the
specifications in effect, often some combination of POSIX and ISO C,
with perhaps some vendor extensions.  Why do you ask?

Andrew.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> > Really?  Such as what?
> 
> Such as "I wrote a perfectly legal C program, and gcc spewed out
> a ton of messages."

What's a "legal C program"?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>> > but I very much like the idea of a gcc that does just what it's told;
>> > making -Wall the default is a big break with tradition.
> Sometimes, we have to be brave to challenge tradition.  The world around
> us is moving and we definitely want GCC to remain competitive.  It is
> hard to define what "it's told" means without tripping over.

I'm finding it hard to understand why "-Wall by default" makes gcc more
competitive.

Andrew.

Re: RFC: -Wall by default

[Arnaud Charlet]

> Well, if you write code so obvious that -Wuninitialized is annoying then:

No, the code is certainly not obvious, and improving -Wuninitialized although
a nice goal is likely to require lots of effort, likely at the expense of
removing some useful warnings.

> either the implementation of -Wuninitialized should be improved, or as you

You can't have it both ways: either -Wuninitialized is indeed improved to the
point where it generates almost no false positives, and then enabling it
by default should be considered/done; or -Wuninitialized does generate
false positives and enabling it by default is likely not a good idea.

Same for -Wmaybe-uninitialized, also part of -Wall.

> are so expert that you can add -Wno-uninitialized.  I think the argument
> cuts both ways.

Who said anything about being "so expert"? IMO that's precisely non
experts who will get the most annoyed here, because they may not understand
why the warning is generated, nor how to disable it.

And IMO, a discussion about a "default" is certainly NOT about experts,
it's precisely a discussion about what would be the best default for most
people (and most people are not experts).

Arno

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> From the list I gave earlier:
>>
>>   -Wformat
>>   -Wimplicit
>>   -Wreturn-type
>>   -Wsequence-point
>>   -Wswitch
>>   -Waddress
>>   -Wstrict-aliasing
>>   -Wenum-compare
>>   -Wreorder
>>   -Wpointer-sign
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code), certainly much more reasonable
> than 'enable -Wall by default', since as I said, switches such as
> -Wuninitialized may generate lots of false positives, annoying people.

by the way, at the exception of a very tiny percentage,
what actually is in -Wall is far more reasonable that an abstract
debate about a warning by default might make it sound.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> From the list I gave earlier:
>>
>>   -Wformat
>>   -Wimplicit
>>   -Wreturn-type
>>   -Wsequence-point
>>   -Wswitch
>>   -Waddress
>>   -Wstrict-aliasing
>>   -Wenum-compare
>>   -Wreorder
>>   -Wpointer-sign
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code), certainly much more reasonable
> than 'enable -Wall by default', since as I said, switches such as
> -Wuninitialized may generate lots of false positives, annoying people.

Well, if you write code so obvious that -Wuninitialized is annoying then:
either the implementation of -Wuninitialized should be improved, or as you
are so expert that you can add -Wno-uninitialized.  I think the argument
cuts both ways.

Re: RFC: -Wall by default

[Arnaud Charlet]

> From the list I gave earlier:
> 
>   -Wformat
>   -Wimplicit
>   -Wreturn-type
>   -Wsequence-point
>   -Wswitch
>   -Waddress
>   -Wstrict-aliasing
>   -Wenum-compare
>   -Wreorder
>   -Wpointer-sign

OK, the above list looks reasonable to me at least as a starting point
that could be a bit refined (not sure -Wstrict-aliasing is so useful by
default for instance for legacy code), certainly much more reasonable
than 'enable -Wall by default', since as I said, switches such as
-Wuninitialized may generate lots of false positives, annoying people.

> > BTW, I don't think -pedantic should be enabled by default, or this
> > wouldn't be "pedantic" anymore.
> 
> I am not proposing that in this discussion.  I was answering a question.

Sure, but this still gives us a perspective and datapoint that what some
users ask and consider as 'obvious' are actually not reasonable requests.

Arno

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:04 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> The simpler requests are -Wall by default.  (there are some occasional
>> -pedantic).
>>
>> The ones I've heard in person -- with the requesters quite competent and
>> respectable programmers -- are in less polite words what I can possibly
>> convey in this discussion.  Adding more options isn't on the top of the list
>> (to quote "I can't go through the 10000 options to figure out which ones
>> will work for something this obvious that should be done by default.")
>
> Could you give some examples of which warnings these people were
> expecting to be "obviously enabled by default" ?

From the list I gave earlier:

  -Wformat
  -Wimplicit
  -Wreturn-type
  -Wsequence-point
  -Wswitch
  -Waddress
  -Wstrict-aliasing
  -Wenum-compare
  -Wreorder
  -Wpointer-sign


>
> I think that would be helpful.
>
> BTW, I don't think -pedantic should be enabled by default, or this wouldn't
> be "pedantic" anymore.

I am not proposing that in this discussion.  I was answering a question.

-- Gaby

Re: RFC: -Wall by default

[Arnaud Charlet]

> The simpler requests are -Wall by default.  (there are some occasional
> -pedantic).
> 
> The ones I've heard in person -- with the requesters quite competent and
> respectable programmers -- are in less polite words what I can possibly
> convey in this discussion.  Adding more options isn't on the top of the list
> (to quote "I can't go through the 10000 options to figure out which ones
> will work for something this obvious that should be done by default.")

Could you give some examples of which warnings these people were
expecting to be "obviously enabled by default" ?

I think that would be helpful.

BTW, I don't think -pedantic should be enabled by default, or this wouldn't
be "pedantic" anymore.

Arno

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

>> Here is a (partial) list:
>>  -Wformat
>>  -Wchar-subscripts
>>  -Wmissing-braces
>>  -Wparentheses
>>  -Wreturn-type
>>  -Wsequence-point
>>  -Wstrict-aliasing
>>  -Wswitch
>>  -Waddress
>>  -Wstrict-overflow
>>  -Warray-bounds
>>  -Wvolatile-register
>>  -Wunknown-pragmas
>>  -Wuninitialized
>>  -Wmaybe-uninitialized
>>  -Wmain
>>  -Wenum-compare
>>  -Wsign-compare
>>  -Wreorder
>>  -Wc++0x-compat
>>  -Wnarrowing
>>  -Wtrigraphs
>>  -Wcomments
>>  -Wpointer-sign
>
> Are there more specific requests than "enable -Wall by default"?  Are
> there requests to remove some options from -Wall?  Are there requests
> to add some options to -Wall?
>
> Note that some of the above depend on optimization flag settings
> (and optimization happening).  Those are not good candidates - I think
> good candidates are those that would still be fully operational with
> -fsyntax-only.

I am not sure -fsyntax-only is a good criteria.
-fsyntax-only limits the amount of work that the compiler does in terms
of code generation, but it should be orthogonal to diagnostic issues.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>
>>> Btw, it would be more reasonable to enable a subset of warnings that
>>> we enable at -Wall by default.
>>
>> Which ones for example?
>>
>> Here is a (partial) list:
>>  -Wformat
>>  -Wchar-subscripts
>>  -Wmissing-braces
>>  -Wparentheses
>>  -Wreturn-type
>>  -Wsequence-point
>>  -Wstrict-aliasing
>>  -Wswitch
>>  -Waddress
>>  -Wstrict-overflow
>>  -Warray-bounds
>>  -Wvolatile-register
>>  -Wunknown-pragmas
>>  -Wuninitialized
>>  -Wmaybe-uninitialized
>>  -Wmain
>>  -Wenum-compare
>>  -Wsign-compare
>>  -Wreorder
>>  -Wc++0x-compat
>>  -Wnarrowing
>>  -Wtrigraphs
>>  -Wcomments
>>  -Wpointer-sign
>
> Are there more specific requests than "enable -Wall by default"?

The simpler requests are -Wall by default.  (there are some occasional
-pedantic).

The ones I've heard in person -- with the requesters quite competent and
respectable programmers -- are in less polite words what I can possibly
convey in this discussion.  Adding more options isn't on the top of the list
(to quote "I can't go through the 10000 options to figure out which ones
will work for something this obvious that should be done by default.")


> Are
> there requests to remove some options from -Wall?  Are there requests
> to add some options to -Wall?
>
> Note that some of the above depend on optimization flag settings
> (and optimization happening).

I think I have long registered my opinion that diagnostics should not depend
on optimizations.  We had had that discussion in the past and I know we
have differing opinions; I am not opening that particular discussion now.
What I would like to say is that if a warning is effective only when
optimization
is turned on, it does not hurt that it enabled by default even if -On
levels would
make it more effective.  I am not going to fight on that though.

> Those are not good candidates - I think
> good candidates are those that would still be fully operational with
> -fsyntax-only.
>
> Richard.

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>
>> Btw, it would be more reasonable to enable a subset of warnings that
>> we enable at -Wall by default.
>
> Which ones for example?
>
> Here is a (partial) list:
>  -Wformat
>  -Wchar-subscripts
>  -Wmissing-braces
>  -Wparentheses
>  -Wreturn-type
>  -Wsequence-point
>  -Wstrict-aliasing
>  -Wswitch
>  -Waddress
>  -Wstrict-overflow
>  -Warray-bounds
>  -Wvolatile-register
>  -Wunknown-pragmas
>  -Wuninitialized
>  -Wmaybe-uninitialized
>  -Wmain
>  -Wenum-compare
>  -Wsign-compare
>  -Wreorder
>  -Wc++0x-compat
>  -Wnarrowing
>  -Wtrigraphs
>  -Wcomments
>  -Wpointer-sign

Are there more specific requests than "enable -Wall by default"?  Are
there requests to remove some options from -Wall?  Are there requests
to add some options to -Wall?

Note that some of the above depend on optimization flag settings
(and optimization happening).  Those are not good candidates - I think
good candidates are those that would still be fully operational with
-fsyntax-only.

Richard.

Re: RFC: -Wall by default

[Pedro Alves]

On 04/05/2012 10:39 AM, Richard Guenther wrote:

... [-Wall + -Werror] ...

> Btw, it would be more reasonable to enable a subset of warnings that
> we enable at -Wall by default.  Notably those that if they were not
> false positives, would lead to undefined behavior at runtime.  Specifically
> I don't think we should warn about unused static functions or variables
> by default.


Yes, I would agree more with something like that.

-- 
Pedro Alves

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

> Btw, it would be more reasonable to enable a subset of warnings that
> we enable at -Wall by default.

Which ones for example?

Here is a (partial) list:
  -Wformat
  -Wchar-subscripts
  -Wmissing-braces
  -Wparentheses
  -Wreturn-type
  -Wsequence-point
  -Wstrict-aliasing
  -Wswitch
  -Waddress
  -Wstrict-overflow
  -Warray-bounds
  -Wvolatile-register
  -Wunknown-pragmas
  -Wuninitialized
  -Wmaybe-uninitialized
  -Wmain
  -Wenum-compare
  -Wsign-compare
  -Wreorder
  -Wc++0x-compat
  -Wnarrowing
  -Wtrigraphs
  -Wcomments
  -Wpointer-sign

 > Notably those that if they were not
> false positives, would lead to undefined behavior at runtime.  Specifically
> I don't think we should warn about unused static functions or variables
> by default.
>
> Richard.
>
>> -- Gaby

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 11:32 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>
>>> Hi,
>>>
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>>
>> I'd just like to explicitly mention (the obvious fact that)
>> that this has the effect of breaking builds of projects that carefully
>> craft their warning set to be able to use -Werror, such as e.g., GDB.
>>
>> Certainly not insurmountable (just add a -Wno-all), but does
>> require actively tweaking the build system.  I'm sure there
>> are many projects affected similarly.
>
> Be assured that I fully appreciate that projects do use -Werror.
> In fact, I do personally encourage people to use -Werror.
>
> However, the issue is very specific: we talking about -Wall.
> If something there is wrong as a default we should have a look
> at it whether it should be there at all, should it be improved, etc.

Btw, it would be more reasonable to enable a subset of warnings that
we enable at -Wall by default.  Notably those that if they were not
false positives, would lead to undefined behavior at runtime.  Specifically
I don't think we should warn about unused static functions or variables
by default.

Richard.

> -- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:32 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Andrew Haley <aph@redhat.com> writes:
>>
>>> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>>>> Andrew Haley <aph@redhat.com> writes:
>>>>
>>>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>>>> Comments?
>>>>>
>>>>> Umm, should this really happen at exactly the same time as C++
>>>>> by default?
>>>>
>>>> I assume that Gaby is talking about making -Wall the default for users
>>>> of GCC.
>>>
>>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>>> but I very much like the idea of a gcc that does just what it's told;
>>> making -Wall the default is a big break with tradition.
>>
>> Yes, that would be a big change.
>
> At the same time we should make 'gcc' optimize as every other compiler.
> Thus, default to -O2.

Which goes back to what I said earlier: it is "does what it is told".

- Gaby

Re: RFC: -Wall by default

[Richard Guenther]

On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor <iant@google.com> wrote:
> Andrew Haley <aph@redhat.com> writes:
>
>> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>>> Andrew Haley <aph@redhat.com> writes:
>>>
>>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>>> Comments?
>>>>
>>>> Umm, should this really happen at exactly the same time as C++
>>>> by default?
>>>
>>> I assume that Gaby is talking about making -Wall the default for users
>>> of GCC.
>>
>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>> but I very much like the idea of a gcc that does just what it's told;
>> making -Wall the default is a big break with tradition.
>
> Yes, that would be a big change.

At the same time we should make 'gcc' optimize as every other compiler.
Thus, default to -O2.

Richard.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>
>> Hi,
>>
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
>
> I'd just like to explicitly mention (the obvious fact that)
> that this has the effect of breaking builds of projects that carefully
> craft their warning set to be able to use -Werror, such as e.g., GDB.
>
> Certainly not insurmountable (just add a -Wno-all), but does
> require actively tweaking the build system.  I'm sure there
> are many projects affected similarly.

Be assured that I fully appreciate that projects do use -Werror.
In fact, I do personally encourage people to use -Werror.

However, the issue is very specific: we talking about -Wall.
If something there is wrong as a default we should have a look
at it whether it should be there at all, should it be improved, etc.

-- Gaby

Re: RFC: -Wall by default

[Pedro Alves]

On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:

> Hi,
> 
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?


I'd just like to explicitly mention (the obvious fact that)
that this has the effect of breaking builds of projects that carefully
craft their warning set to be able to use -Werror, such as e.g., GDB.

Certainly not insurmountable (just add a -Wno-all), but does
require actively tweaking the build system.  I'm sure there
are many projects affected similarly.

-- 
Pedro Alves

Re: RFC: -Wall by default

[Robert Dewar]

On 4/4/2012 2:02 PM, Gabriel Dos Reis wrote:

> The interesting thing about -Wall is that it is pretty safe, for the most part,
> in terms of false positives.

And, for the record, I find lots of false positives, the front end of
GNAT has a lot of junk initialiations marked "keep back end quiet".
>
> -- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

> Sometimes, we have to be brave to challenge tradition.  The world around
> us is moving and we definitely want GCC to remain competitive.  It is
> hard to define what "it's told" means without tripping over.
>
> The interesting thing about -Wall is that it is pretty safe, for the most part,
> in terms of false positives.

Well I find it too big a change to make, if people want warnings, it 
really is not that hard to ask for them!
>
> -- Gaby

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> Really?  Such as what?

Such as "I wrote a perfectly legal C program, and gcc spewed out
a ton of messages."

Andrew.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 1:06 PM, Jeff Law <law@redhat.com> wrote:
> On 04/04/2012 12:04 PM, Gabriel Dos Reis wrote:
>>
>> On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law<law@redhat.com>  wrote:
>>>
>>> On 04/04/2012 08:56 AM, Ian Lance Taylor wrote:
>>>>
>>>>
>>>> Andrew Haley<aph@redhat.com>    writes:
>>>>
>>>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>>>
>>>>>>
>>>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>>>> Comments?
>>>>>
>>>>>
>>>>>
>>>>> Umm, should this really happen at exactly the same time as C++
>>>>> by default?
>>>>
>>>>
>>>>
>>>> I assume that Gaby is talking about making -Wall the default for users
>>>> of GCC.
>>>
>>>
>>> If so, that seems awful presumptuous to me.
>>
>>
>> We do have regular requests for this, so it is not just out of thin air.
>
> Perhaps, but I think that changing the default like this is far too
> invasive.  GCC should do what it's told, if a user asks for warnings, give
> them, if they don't, then don't.

It is hard to define "what it is told" means -- we are already in gray zone.

> I suspect changing the default like this will generate a flood of complaints.

Really?  Such as what?

If we get floods of complaints, that can only that -Wall too many
false positives;
but I don't think it does.  We have been careful over the years to
watch for that effect.

>
> jeff

Re: RFC: -Wall by default

[Jeff Law]

On 04/04/2012 12:04 PM, Gabriel Dos Reis wrote:
> On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law<law@redhat.com>  wrote:
>> On 04/04/2012 08:56 AM, Ian Lance Taylor wrote:
>>>
>>> Andrew Haley<aph@redhat.com>    writes:
>>>
>>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>>
>>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>>> Comments?
>>>>
>>>>
>>>> Umm, should this really happen at exactly the same time as C++
>>>> by default?
>>>
>>>
>>> I assume that Gaby is talking about making -Wall the default for users
>>> of GCC.
>>
>> If so, that seems awful presumptuous to me.
>
> We do have regular requests for this, so it is not just out of thin air.
Perhaps, but I think that changing the default like this is far too 
invasive.  GCC should do what it's told, if a user asks for warnings, 
give them, if they don't, then don't.   I suspect changing the default 
like this will generate a flood of complaints.

jeff

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law <law@redhat.com> wrote:
> On 04/04/2012 08:56 AM, Ian Lance Taylor wrote:
>>
>> Andrew Haley<aph@redhat.com>  writes:
>>
>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>
>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>> Comments?
>>>
>>>
>>> Umm, should this really happen at exactly the same time as C++
>>> by default?
>>
>>
>> I assume that Gaby is talking about making -Wall the default for users
>> of GCC.
>
> If so, that seems awful presumptuous to me.

We do have regular requests for this, so it is not just out of thin air.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 10:07 AM, Andrew Haley <aph@redhat.com> wrote:
> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>> Andrew Haley <aph@redhat.com> writes:
>>
>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>> Comments?
>>>
>>> Umm, should this really happen at exactly the same time as C++
>>> by default?
>>
>> I assume that Gaby is talking about making -Wall the default for users
>> of GCC.
>
> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
> but I very much like the idea of a gcc that does just what it's told;
> making -Wall the default is a big break with tradition.

Sometimes, we have to be brave to challenge tradition.  The world around
us is moving and we definitely want GCC to remain competitive.  It is
hard to define what "it's told" means without tripping over.

The interesting thing about -Wall is that it is pretty safe, for the most part,
in terms of false positives.

-- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 9:56 AM, Ian Lance Taylor <iant@google.com> wrote:
> Andrew Haley <aph@redhat.com> writes:
>
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this really happen at exactly the same time as C++
>> by default?
>
> I assume that Gaby is talking about making -Wall the default for users
> of GCC.

Exactly.  Our bugzilla databases has lot of requests in this spirit.
My personal opinion is that we are doing ourselves a disservice
by ignoring them.  It is high time.

-- Gaby

Re: RFC: -Wall by default

[Ian Lance Taylor]

Andrew Haley <aph@redhat.com> writes:

> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>> Andrew Haley <aph@redhat.com> writes:
>> 
>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>> Comments?
>>>
>>> Umm, should this really happen at exactly the same time as C++
>>> by default?
>> 
>> I assume that Gaby is talking about making -Wall the default for users
>> of GCC.
>
> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
> but I very much like the idea of a gcc that does just what it's told;
> making -Wall the default is a big break with tradition.

Yes, that would be a big change.

But we already use -Wall when building GCC itself, so that would not be
a change at all.

Ian

Re: RFC: -Wall by default

[Jeff Law]

On 04/04/2012 08:56 AM, Ian Lance Taylor wrote:
> Andrew Haley<aph@redhat.com>  writes:
>
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this really happen at exactly the same time as C++
>> by default?
>
> I assume that Gaby is talking about making -Wall the default for users
> of GCC.
If so, that seems awful presumptuous to me.

jeff

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
> Andrew Haley <aph@redhat.com> writes:
> 
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this really happen at exactly the same time as C++
>> by default?
> 
> I assume that Gaby is talking about making -Wall the default for users
> of GCC.

Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
but I very much like the idea of a gcc that does just what it's told;
making -Wall the default is a big break with tradition.

Andrew.

Re: RFC: -Wall by default

[Ian Lance Taylor]

Andrew Haley <aph@redhat.com> writes:

> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
> Umm, should this really happen at exactly the same time as C++
> by default?

I assume that Gaby is talking about making -Wall the default for users
of GCC.

The C++ issue does not affect users of GCC at all.  It only affects
people who build GCC.

Ian

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 7:19 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 2:14 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote:
>>> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>>> Comments?
>>>>
>>>> Umm, should this really happen at exactly the same time as C++
>>>> by default?
>>>
>>> I consider it a separate issue.
>>>
>>> -Wall is a primary a service to GCC users (which GCC is already
>>> using internally.)
>>>
>>> Switching to compile with C++ compiler is an internal
>>> compiler infrastructure issue that should be independent
>>> of the services we provide to the broader C++ community.
>>
>> It's certainly a separate issue, but the set of C++ warnings is
>> very different, and to avoid unnecessary chaos it might be good
>> to stage the changes.
>
> We already use -Wall for both the stage1 C and the stage2+ C++ compiles.
> Only stage2+ use -Werror though.

Exactly.  I am suggesting to turn on -Werror by default.

-- Gaby

Re: RFC: -Wall by default

[Richard Guenther]

On Wed, Apr 4, 2012 at 2:14 PM, Andrew Haley <aph@redhat.com> wrote:
> On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote:
>> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley <aph@redhat.com> wrote:
>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>> Comments?
>>>
>>> Umm, should this really happen at exactly the same time as C++
>>> by default?
>>
>> I consider it a separate issue.
>>
>> -Wall is a primary a service to GCC users (which GCC is already
>> using internally.)
>>
>> Switching to compile with C++ compiler is an internal
>> compiler infrastructure issue that should be independent
>> of the services we provide to the broader C++ community.
>
> It's certainly a separate issue, but the set of C++ warnings is
> very different, and to avoid unnecessary chaos it might be good
> to stage the changes.

We already use -Wall for both the stage1 C and the stage2+ C++ compiles.
Only stage2+ use -Werror though.

Richard.

> Andrew.

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote:
> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this really happen at exactly the same time as C++
>> by default?
> 
> I consider it a separate issue.
> 
> -Wall is a primary a service to GCC users (which GCC is already
> using internally.)
> 
> Switching to compile with C++ compiler is an internal
> compiler infrastructure issue that should be independent
> of the services we provide to the broader C++ community.

It's certainly a separate issue, but the set of C++ warnings is
very different, and to avoid unnecessary chaos it might be good
to stage the changes.

Andrew.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley <aph@redhat.com> wrote:
> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
> Umm, should this really happen at exactly the same time as C++
> by default?

I consider it a separate issue.

-Wall is a primary a service to GCC users (which GCC is already
using internally.)

Switching to compile with C++ compiler is an internal
compiler infrastructure issue that should be independent
of the services we provide to the broader C++ community.

-- Gaby

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?

Umm, should this really happen at exactly the same time as C++
by default?

Andrew.

Re: RFC: -Wall by default

[Rick Hodgin]

An idea whose time has come.

--- On Wed, 4/4/12, Gabriel Dos Reis wrote:
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?

RFC: -Wall by default

[Gabriel Dos Reis]

Hi,

For GCC-4.8, I would like to turn on -Wall by default.
Comments?

-- Gaby