On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> The goal is to fix PR7651 and convert Wextra into a super-option, that
> is an -W* option that just enables other options but it doesn't emit
> warnings by itself (other super-options are Wall and Wunused).
Thanks again for tackling this.
These issues are tricky because on the one hand we don't want too many
different options, and on the other hand we want to give people the
control they are asking for with regard to turning off warnings.
Yeah, I know but I thought it was a goal that every warning is
controlled by some option. I also think (and is under discussion
elsewhere) that super-options (as Wall) should only enable other
options and don't have associated any warning to themselves.
> * Subscripting an array which has been declared register.
>
> * Taking the address of a variable which has been declared register.
Hmmm. In the C frontend these are pedwarns. But the C++ frontend
doesn't have pedwarns. And maybe C++ doesn't require these warnings
anyhow, I don't know. -Winvalid-register anyone?
If we don't require them, we could drop them. Also, there is already
a patch in the queue [1] to name this -Waddress-of-register. I could
update it with Winvalid-register.
[1] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01676.html
> * A base class is not initialized in a derived class' copy constructor.
I think -Wuninitialized.
If none disagrees, OK.
> * A non-static reference or non-static const member appears in a class
> without constructors.
-Wbad-code. Or, I dunno, how about -Wmissing-field-initializers?
Wbad-code is vague. -Wmissing-field-initializers seems fine and also
-Wuninitialized. Any other opinion?
There is a patch and a discussion about this:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01842.html
> * Ambiguous virtual bases (virtual base inaccessible due to
> ambiguity). (There is also an unconditional warning for direct base
> inaccessible due to ambiguity)
What do you think of -Woverloaded-virtual?
Fine to me but I am no C++ expert and we have to think if the users of
Woverloaded-virtual will be happy with this additional warning.
> * An enumerator and a non-enumerator both appear in a conditional
> expression. (There is also an unconditional warning for two different
> enumeral types used in a conditional expression).
Maybe we should rename -Wswitch-enum to -Wenum and wrap these warnings
under there as well.
I don't think they have much to do with each other. Moreover, this
warning applies only to C++. What about -Wconversion ?
Again, there is patch with testcases here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01842.html
> * A function can return either with or without a value.
I give up.
:-) None said it was going to be easy. We have a warning similar to this:
-Wreturn-type
warn about any "return" statement with no return-value in a
function whose return-type is not "void".
However, this is enabled by Wall and the one from Wextra surely
produces false positives (I guess that is the reason it is in Wextra).
-Wreturn-type-may ?
> * An expression-statement or the left-hand side of a comma expression
> contains no side effects. For example, an expression such as x[i,j].
> This is also warned by Wunused-value. In addition, Wextra enables
> Wunused-value but this is not documented (and -Wunused-value is
> already enabled by -Wall).
I think this should just be -WUnused-value.
So do I. There is a patch to implement just that here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00440.html
> * An unsigned value is compared against zero with < or >=.
> Walways-true claims to warn for this but it doesn't. There is also an
> unconditional warning for expressions that are always true or false
> due to the range of types.
-Walways-true should warn for this.
No, I think it shouldn't but let's leave this for now, please. I need
to do a bit more of research and archive archaeology to properly
justify why I think that this is a Really Bad Idea (TM). Or we could
just drop the idea @ kernel.org and see what happens. Any brave
volunteer?
> In ./gcc/config/sh/symbian.c:158 there is a warning enabled by Wextra
> with the following code (notice the OPT_Wattributes) :
>
> /* We ignore the dllimport attribute for inline member functions.
> This differs from MSVC behavior which treats it like GNUC
> 'extern inline' extension. */
> else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_INLINE (decl))
> {
> if (extra_warnings)
> warning (OPT_Wattributes, "inline function %q+D is declared as "
> "dllimport: attribute ignored",
> decl);
> return false;
> }
Just drop the test of extra_warnings, I think.
OK. I just found out that Wattributes is enabled by default. So
dropping it from Wextra seems appropriate.
> Finally, the manual page claims that Wextra warns for any of several
> floating-point events that often indicate errors, such as overflow,
> underflow, loss of precision, etc. I wasn't able to find any instance
> of this. I am fairly sure that Wextra doesn't do such thing.
I have no idea what that refers to.
So we just remove it from doc/invoke.texi ?
Thanks again. Hope this helps. No doubt others will disagree with
some of my comments.
It helps a lot. Thanks to you for taking the quiz.
Cheers,
Manuel.
