Re: Use [warning enabled by default] for default warnings
Richard Biener richard.guent...@gmail.com writes:
On Sun, Feb 9, 2014 at 9:30 PM, Robert Dewar de...@adacore.com wrote:
On 2/9/2014 3:23 PM, Richard Sandiford wrote:
can't we just reword the one warning where there is an ambiguity to
avoid the confusion, rather than creating such an earthquake, which
as Arno says, really has zero advantages to Ada programmers, and clear
disadvantages .. to me [enabled by default] is already awfully long!
Well, since the Ada part has been rejected I think we just need to
consider this from the non-Ada perspective. And IMO there's zero
chance that each new warning will be audited for whether the
[enabled by default] will be unambiguous. The fact that this
particular warning caused confusion and someone actually reported
it doesn't mean that there are no other warnings like that. E.g.:
-fprefetch-loop-arrays is not supported with -Os [enabled by default]
could also be misunderstood, especially if working on an existing codebase
with an existing makefile. And the effect for:
pragma simd ignored because -fcilkplus is not enabled [enabled by
default]
is a bit unfortunate. Those were just two examples -- I'm sure I could
pick more.
Indeed, worrisome examples,
a shorter substitute would be [default warning]
???
Or print nothing at all? After all [...] was supposed to tell people how
to disable the warning! If there isn't a way to do that ... maybe instead
print [-w]? hmm, all existing [...] are positive so we'd have to print
-no-w which doesn't exist. Bah. So there isn't a way to negate -w
on the commandline to only get default warnings enabled again.
OK, this version drops the [enabled by default] altogether.
Tested as before. OK to install?
Thanks,
Richard
gcc/
* opts.c (option_name): Remove enabled by default rider.
gcc/testsuite/
* gcc.dg/gomp/simd-clones-5.c: Update comment for new warning message.
Index: gcc/opts.c
===
--- gcc/opts.c 2014-02-10 20:36:32.380197329 +
+++ gcc/opts.c 2014-02-10 20:58:45.894502379 +
@@ -2216,14 +2216,10 @@ option_name (diagnostic_context *context
return xstrdup (cl_options[option_index].opt_text);
}
/* A warning without option classified as an error. */
- else if (orig_diag_kind == DK_WARNING || orig_diag_kind == DK_PEDWARN
- || diag_kind == DK_WARNING)
-{
- if (context-warning_as_error_requested)
- return xstrdup (cl_options[OPT_Werror].opt_text);
- else
- return xstrdup (_(enabled by default));
-}
+ else if ((orig_diag_kind == DK_WARNING || orig_diag_kind == DK_PEDWARN
+ || diag_kind == DK_WARNING)
+ context-warning_as_error_requested)
+return xstrdup (cl_options[OPT_Werror].opt_text);
else
return NULL;
}
Index: gcc/testsuite/gcc.dg/gomp/simd-clones-5.c
===
--- gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-10 20:36:32.380197329
+
+++ gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-10 21:00:32.549412313
+
@@ -3,7 +3,7 @@
/* ?? The -w above is to inhibit the following warning for now:
a.c:2:6: warning: AVX vector argument without AVX enabled changes
- the ABI [enabled by default]. */
+ the ABI. */
#pragma omp declare simd notinbranch simdlen(4)
void foo (int *a)
Re: Use [warning enabled by default] for default warnings
On 02/09/2014 09:00 PM, Richard Sandiford wrote: + return xstrdup (_(warning enabled by default)); I think this is still wrong because this message really means, this warning cannot be controlled with a warning flag, but it can likely be switched off by other means. I don't think it's helpful. In my opinion, it is better to make this message obsolete by introducing the missing warning flags. -- Florian Weimer / Red Hat Product Security Team
Re: Use [warning enabled by default] for default warnings
On 2/11/2014 4:45 AM, Richard Sandiford wrote:
OK, this version drops the [enabled by default] altogether.
Tested as before. OK to install?
Still a huge earthquake in terms of affecting test suites and
baselines of many users. is it really worth it? In the case of
GNAT we have only recently started tagging messages in this
way, so changes would not be so disruptive, and we can debate
following whatever gcc does, but I think it is important to
understand that any change in this area is a big one in terms
of impact on users.
Thanks,
Richard
gcc/
* opts.c (option_name): Remove enabled by default rider.
gcc/testsuite/
* gcc.dg/gomp/simd-clones-5.c: Update comment for new warning message.
Index: gcc/opts.c
===
--- gcc/opts.c 2014-02-10 20:36:32.380197329 +
+++ gcc/opts.c 2014-02-10 20:58:45.894502379 +
@@ -2216,14 +2216,10 @@ option_name (diagnostic_context *context
return xstrdup (cl_options[option_index].opt_text);
}
/* A warning without option classified as an error. */
- else if (orig_diag_kind == DK_WARNING || orig_diag_kind == DK_PEDWARN
- || diag_kind == DK_WARNING)
-{
- if (context-warning_as_error_requested)
- return xstrdup (cl_options[OPT_Werror].opt_text);
- else
- return xstrdup (_(enabled by default));
-}
+ else if ((orig_diag_kind == DK_WARNING || orig_diag_kind == DK_PEDWARN
+ || diag_kind == DK_WARNING)
+ context-warning_as_error_requested)
+return xstrdup (cl_options[OPT_Werror].opt_text);
else
return NULL;
}
Index: gcc/testsuite/gcc.dg/gomp/simd-clones-5.c
===
--- gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-10 20:36:32.380197329
+
+++ gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-10 21:00:32.549412313
+
@@ -3,7 +3,7 @@
/* ?? The -w above is to inhibit the following warning for now:
a.c:2:6: warning: AVX vector argument without AVX enabled changes
- the ABI [enabled by default]. */
+ the ABI. */
#pragma omp declare simd notinbranch simdlen(4)
void foo (int *a)
Re: Use [warning enabled by default] for default warnings
Robert Dewar de...@adacore.com writes: On 2/11/2014 4:45 AM, Richard Sandiford wrote: OK, this version drops the [enabled by default] altogether. Tested as before. OK to install? Still a huge earthquake in terms of affecting test suites and baselines of many users. is it really worth it? In the case of GNAT we have only recently started tagging messages in this way, so changes would not be so disruptive, and we can debate following whatever gcc does, but I think it is important to understand that any change in this area is a big one in terms of impact on users. The patch deliberately didn't affect Ada's diagnostic routines given your comments from the first round. Calling this a huge earthquake for other languages seems like a gross overstatement. I don't think gcc, g++, gfortran, etc, have ever made a commitment to producing textually identical warnings and errors for given inputs across different releases. It seems ridiculous to require that, especially if it stands in the way of improving the diagnostics or introducing finer-grained -W control. E.g. Florian's complaint was that we shouldn't have warnings that are not under the control of any -W options. But by your logic we couldn't change that either, because all those [enabled by default]s would become [-Wnew-option]s. Thanks, Richard
Re: Use [warning enabled by default] for default warnings
On Tue, Feb 11, 2014 at 1:48 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Robert Dewar de...@adacore.com writes: On 2/11/2014 4:45 AM, Richard Sandiford wrote: OK, this version drops the [enabled by default] altogether. Tested as before. OK to install? Still a huge earthquake in terms of affecting test suites and baselines of many users. is it really worth it? In the case of GNAT we have only recently started tagging messages in this way, so changes would not be so disruptive, and we can debate following whatever gcc does, but I think it is important to understand that any change in this area is a big one in terms of impact on users. The patch deliberately didn't affect Ada's diagnostic routines given your comments from the first round. Calling this a huge earthquake for other languages seems like a gross overstatement. I don't think gcc, g++, gfortran, etc, have ever made a commitment to producing textually identical warnings and errors for given inputs across different releases. It seems ridiculous to require that, especially if it stands in the way of improving the diagnostics or introducing finer-grained -W control. E.g. Florian's complaint was that we shouldn't have warnings that are not under the control of any -W options. But by your logic we couldn't change that either, because all those [enabled by default]s would become [-Wnew-option]s. Yeah, I think Roberts argument is a red herring - there are loads of diagnostic changes every release so you cannot expect those to be stable. I'm fine with dropping the [enabled by default] as in the patch, but lets hear another ok before making the change. Thanks, Richard. Thanks, Richard
Re: Use [warning enabled by default] for default warnings
On 2/11/2014 7:48 AM, Richard Sandiford wrote: The patch deliberately didn't affect Ada's diagnostic routines given your comments from the first round. Calling this a huge earthquake for other languages seems like a gross overstatement. Actually it's much less of an impact for Ada for two reasons. First we only just started tagging warnings. In fact we have only just released an official version with the facility for tagging warnings. Second, this tagging of warnings is not the default (that would have been a big earthquake) but you have to turn it on explicitly. But I do indeed think it will have a significant impact for users of other languages, where this has been done for a while, and if I am not mistaken, done by default? I don't think gcc, g++, gfortran, etc, have ever made a commitment to producing textually identical warnings and errors for given inputs across different releases. It seems ridiculous to require that, especially if it stands in the way of improving the diagnostics or introducing finer-grained -W control. E.g. Florian's complaint was that we shouldn't have warnings that are not under the control of any -W options. But by your logic we couldn't change that either, because all those [enabled by default]s would become [-Wnew-option]s. I am not saying you can't change it, just that it is indeed a big earthquake. No of course there is no commitment not to make changes. But you have to be aware that when you make changes like this, the impact is very significant in real production environments, and gcc is as you know extensively used in such environments. What I am saying here is that this is worth some discussion on what the best approach is. Ideally indeed it would be better if all warnings were controlled by some specific warning category. I am not sure a warning switch that default-covered all otherwise uncovered cases (as suggested by one person at least) would be a worthwhile approach.
Re: Use [warning enabled by default] for default warnings
Robert Dewar de...@adacore.com writes: I don't think gcc, g++, gfortran, etc, have ever made a commitment to producing textually identical warnings and errors for given inputs across different releases. It seems ridiculous to require that, especially if it stands in the way of improving the diagnostics or introducing finer-grained -W control. E.g. Florian's complaint was that we shouldn't have warnings that are not under the control of any -W options. But by your logic we couldn't change that either, because all those [enabled by default]s would become [-Wnew-option]s. I am not saying you can't change it, just that it is indeed a big earthquake. No of course there is no commitment not to make changes. But you have to be aware that when you make changes like this, the impact is very significant in real production environments, and gcc is as you know extensively used in such environments. What I am saying here is that this is worth some discussion on what the best approach is. But what's the basis for that discussion going to be? I first made this suggestion on gcc@, which is the best list we have for getting user feedback, and no user made this objection. And when I worked in an environment where I had direct contact with GCC-using customers, none of them gave any indication that they were expecting textual stability between releases. If you know of people who are using non-Ada languages this way then please describe their set-up. If you don't, how are we going to know how such hypothetical users are going to react? E.g. how many of those users will have heard of sed? I thought the trend these days was to move towards -Werror, so that for many people the expected output is to get no warnings at all. And bear in mind that the kind of warnings that are not under -W control tend to be those that are so likely to be a mistake that no-one has ever had an incentive to make them optional. I find it hard to believe that significant numbers of users are not fixing the sources of those warnings and are instead requiring every release of GCC to produce warnings with a particular wording. Thanks, Richard
Re: Use [warning enabled by default] for default warnings
On 2/11/2014 9:36 AM, Richard Sandiford wrote: I find it hard to believe that significant numbers of users are not fixing the sources of those warnings and are instead requiring every release of GCC to produce warnings with a particular wording. Good enough for me, I think it is OK to make the change.
Re: Use [warning enabled by default] for default warnings
Am 2014-02-11 15:36, schrieb Richard Sandiford: I thought the trend these days was to move towards -Werror, so that for many people the expected output is to get no warnings at all. And bear in mind that the kind of warnings that are not under -W control tend to be those that are so likely to be a mistake that no-one has ever had an incentive to make them optional. I find it hard to believe that significant numbers of users are not fixing the sources of those warnings and are instead requiring every release of GCC to produce warnings with a particular wording. Hi, actually at my site we turn on more and more warnings into errors, but we do it warning by warning with more -Werror=..., so the fine-grained warning changes are really nice for us. The problem we face with [enabled by default] warnings is not that there are no options to turn these warnings off (we _want_ these warnings), but this also means there are no corresponding -Werror= options (and also no -Werror=enabled-by-default or -Werror=default-warnings). And pure -Werror turns all other warnings we want to see into errors too :(. regards, Franz
Re: Use [warning enabled by default] for default warnings
On Tue, Feb 11, 2014 at 5:20 AM, Richard Biener richard.guent...@gmail.com wrote: On Tue, Feb 11, 2014 at 1:48 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Robert Dewar de...@adacore.com writes: On 2/11/2014 4:45 AM, Richard Sandiford wrote: OK, this version drops the [enabled by default] altogether. Tested as before. OK to install? Still a huge earthquake in terms of affecting test suites and baselines of many users. is it really worth it? In the case of GNAT we have only recently started tagging messages in this way, so changes would not be so disruptive, and we can debate following whatever gcc does, but I think it is important to understand that any change in this area is a big one in terms of impact on users. The patch deliberately didn't affect Ada's diagnostic routines given your comments from the first round. Calling this a huge earthquake for other languages seems like a gross overstatement. I don't think gcc, g++, gfortran, etc, have ever made a commitment to producing textually identical warnings and errors for given inputs across different releases. It seems ridiculous to require that, especially if it stands in the way of improving the diagnostics or introducing finer-grained -W control. E.g. Florian's complaint was that we shouldn't have warnings that are not under the control of any -W options. But by your logic we couldn't change that either, because all those [enabled by default]s would become [-Wnew-option]s. Yeah, I think Roberts argument is a red herring - there are loads of diagnostic changes every release so you cannot expect those to be stable. I'm fine with dropping the [enabled by default] as in the patch, but lets hear another ok before making the change. I think this change is OK. It's obviously not a great situation, but enabled by default is fairly useless information, so this seems like a marginal improvement. Ian
Re: Use [warning enabled by default] for default warnings
On Sun, Feb 9, 2014 at 9:30 PM, Robert Dewar de...@adacore.com wrote: On 2/9/2014 3:23 PM, Richard Sandiford wrote: can't we just reword the one warning where there is an ambiguity to avoid the confusion, rather than creating such an earthquake, which as Arno says, really has zero advantages to Ada programmers, and clear disadvantages .. to me [enabled by default] is already awfully long! Well, since the Ada part has been rejected I think we just need to consider this from the non-Ada perspective. And IMO there's zero chance that each new warning will be audited for whether the [enabled by default] will be unambiguous. The fact that this particular warning caused confusion and someone actually reported it doesn't mean that there are no other warnings like that. E.g.: -fprefetch-loop-arrays is not supported with -Os [enabled by default] could also be misunderstood, especially if working on an existing codebase with an existing makefile. And the effect for: pragma simd ignored because -fcilkplus is not enabled [enabled by default] is a bit unfortunate. Those were just two examples -- I'm sure I could pick more. Indeed, worrisome examples, a shorter substitute would be [default warning] ??? Or print nothing at all? After all [...] was supposed to tell people how to disable the warning! If there isn't a way to do that ... maybe instead print [-w]? hmm, all existing [...] are positive so we'd have to print -no-w which doesn't exist. Bah. So there isn't a way to negate -w on the commandline to only get default warnings enabled again. Richard. Thanks, Richard
Use [warning enabled by default] for default warnings
We print [-Wfoo] after a warning that was enabled by the -Wfoo option, which is pretty clear. But for warnings that have no -W option we just print [enabled by default], which leads to the question of _what_ is enabled by default. As shown by: http://gcc.gnu.org/ml/gcc/2014-01/msg00234.html it invites the wrong interpretation for things like: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] IMO the natural assumption is that gnu++11 is enabled by default, which is how Lars also read it. There seemed to be support for using warning enabled by default instead, so this patch does that. Tested on x86_64-linux-gnu. OK to install? I'll post an Ada patch separately. Thanks, Richard gcc/ * opts.c (option_name): Use warning enabled by default rather than just enabled by default. gcc/testsuite/ * gcc.dg/gomp/simd-clones-5.c: Update comment for new warning message. Index: gcc/opts.c === --- gcc/opts.c 2014-02-09 12:07:06.237317560 + +++ gcc/opts.c 2014-02-09 12:07:06.371318597 + @@ -,7 +,7 @@ option_name (diagnostic_context *context if (context-warning_as_error_requested) return xstrdup (cl_options[OPT_Werror].opt_text); else - return xstrdup (_(enabled by default)); + return xstrdup (_(warning enabled by default)); } else return NULL; Index: gcc/testsuite/gcc.dg/gomp/simd-clones-5.c === --- gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-09 12:07:06.237317560 + +++ gcc/testsuite/gcc.dg/gomp/simd-clones-5.c 2014-02-09 12:07:06.371318597 + @@ -3,7 +3,7 @@ /* ?? The -w above is to inhibit the following warning for now: a.c:2:6: warning: AVX vector argument without AVX enabled changes - the ABI [enabled by default]. */ + the ABI [warning enabled by default]. */ #pragma omp declare simd notinbranch simdlen(4) void foo (int *a)
[Ada] Use [warning enabled by default] for default warnings
This switches Ada from using [enabled by default] to [warning enabled
by default] for consistency with:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html
Tested on x86_64-linux-gnu. OK if the above patch goes in?
Thanks,
Richard
gcc/ada/
* erroutc.adb (Output_Msg_Text): Use [warning enabled by default].
* err_vars.ads, errout.ads, gnat_ugn.texi: Update comments and
documentation accordingly.
Index: gcc/ada/erroutc.adb
===
--- gcc/ada/erroutc.adb 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/erroutc.adb 2014-02-09 20:02:58.640471235 +
@@ -456,7 +456,7 @@ package body Erroutc is
if Warn and then Warn_Chr /= ' ' then
if Warn_Chr = '?' then
-Warn_Tag := new String'( [enabled by default]);
+Warn_Tag := new String'( [warning enabled by default]);
elsif Warn_Chr in 'a' .. 'z' then
Warn_Tag := new String'( [-gnatw Warn_Chr ']');
Index: gcc/ada/err_vars.ads
===
--- gcc/ada/err_vars.ads2014-02-09 20:02:00.971968883 +
+++ gcc/ada/err_vars.ads2014-02-09 20:02:58.639471226 +
@@ -141,8 +141,8 @@ package Err_Vars is
-- Setting is irrelevant if no insertion character is present. Note
-- that it is not necessary to reset this after using it, since the proper
-- procedure is always to set it before issuing such a message. Note that
- -- the warning documentation tag is always [enabled by default] in the
- -- case where this flag is True.
+ -- the warning documentation tag is always [warning enabled by default]
+ -- in the case where this flag is True.
Error_Msg_String : String (1 .. 4096);
Error_Msg_Strlen : Natural;
Index: gcc/ada/errout.ads
===
--- gcc/ada/errout.ads 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/errout.ads 2014-02-09 20:02:58.639471226 +
@@ -287,8 +287,8 @@ package Errout is
--Insertion character ?? (Two question marks: default warning)
-- Like ?, but if the flag Warn_Doc_Switch is True, adds the string
- -- [enabled by default] at the end of the warning message. For
- -- continuations, use this in each continuation message.
+ -- [warning enabled by default] at the end of the warning message.
+ -- For continuations, use this in each continuation message.
--Insertion character ?x? (warning with switch)
-- Like ?, but if the flag Warn_Doc_Switch is True, adds the string
Index: gcc/ada/gnat_ugn.texi
===
--- gcc/ada/gnat_ugn.texi 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/gnat_ugn.texi 2014-02-09 20:02:58.644471270 +
@@ -5055,8 +5055,8 @@ indexed components, slices, and selected
@cindex @option{-gnatw.d} (@command{gcc})
If this switch is set, then warning messages are tagged, either with
the string ``@option{-gnatw?}'' showing which switch controls the warning,
-or with ``[enabled by default]'' if the warning is not under control of a
-specific @option{-gnatw?} switch. This mode is off by default, and is not
+or with ``[warning enabled by default]'' if the warning is not under control
+of a specific @option{-gnatw?} switch. This mode is off by default, and is not
affected by the use of @code{-gnatwa}.
@item -gnatw.D
Re: Use [warning enabled by default] for default warnings
On 2/9/2014 3:00 PM, Richard Sandiford wrote: We print [-Wfoo] after a warning that was enabled by the -Wfoo option, which is pretty clear. But for warnings that have no -W option we just print [enabled by default], which leads to the question of _what_ is enabled by default. As shown by: http://gcc.gnu.org/ml/gcc/2014-01/msg00234.html it invites the wrong interpretation for things like: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] IMO the natural assumption is that gnu++11 is enabled by default, which is how Lars also read it. There seemed to be support for using warning enabled by default instead, so this patch does that. Tested on x86_64-linux-gnu. OK to install? Sounds like an earthquake patch from the point of view of test suite baselines! I'll post an Ada patch separately. Will definitely have a big impact on the Ada test suite. Fine to post the Ada patch (which is of course trivial as a patch), but we will have to coordinate installing it with a pass through test base lines.
Re: [Ada] Use [warning enabled by default] for default warnings
On 2/9/2014 3:03 PM, Richard Sandiford wrote:
This switches Ada from using [enabled by default] to [warning enabled
by default] for consistency with:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html
Tested on x86_64-linux-gnu. OK if the above patch goes in?
I would say hold off on this until we can find the time
to coordinate updating our test suite, which we will do
as fast as possible.
Thanks,
Richard
gcc/ada/
* erroutc.adb (Output_Msg_Text): Use [warning enabled by default].
* err_vars.ads, errout.ads, gnat_ugn.texi: Update comments and
documentation accordingly.
Index: gcc/ada/erroutc.adb
===
--- gcc/ada/erroutc.adb 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/erroutc.adb 2014-02-09 20:02:58.640471235 +
@@ -456,7 +456,7 @@ package body Erroutc is
if Warn and then Warn_Chr /= ' ' then
if Warn_Chr = '?' then
-Warn_Tag := new String'( [enabled by default]);
+Warn_Tag := new String'( [warning enabled by default]);
elsif Warn_Chr in 'a' .. 'z' then
Warn_Tag := new String'( [-gnatw Warn_Chr ']');
Index: gcc/ada/err_vars.ads
===
--- gcc/ada/err_vars.ads2014-02-09 20:02:00.971968883 +
+++ gcc/ada/err_vars.ads2014-02-09 20:02:58.639471226 +
@@ -141,8 +141,8 @@ package Err_Vars is
-- Setting is irrelevant if no insertion character is present. Note
-- that it is not necessary to reset this after using it, since the proper
-- procedure is always to set it before issuing such a message. Note that
- -- the warning documentation tag is always [enabled by default] in the
- -- case where this flag is True.
+ -- the warning documentation tag is always [warning enabled by default]
+ -- in the case where this flag is True.
Error_Msg_String : String (1 .. 4096);
Error_Msg_Strlen : Natural;
Index: gcc/ada/errout.ads
===
--- gcc/ada/errout.ads 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/errout.ads 2014-02-09 20:02:58.639471226 +
@@ -287,8 +287,8 @@ package Errout is
--Insertion character ?? (Two question marks: default warning)
-- Like ?, but if the flag Warn_Doc_Switch is True, adds the string
- -- [enabled by default] at the end of the warning message. For
- -- continuations, use this in each continuation message.
+ -- [warning enabled by default] at the end of the warning message.
+ -- For continuations, use this in each continuation message.
--Insertion character ?x? (warning with switch)
-- Like ?, but if the flag Warn_Doc_Switch is True, adds the string
Index: gcc/ada/gnat_ugn.texi
===
--- gcc/ada/gnat_ugn.texi 2014-02-09 20:02:00.971968883 +
+++ gcc/ada/gnat_ugn.texi 2014-02-09 20:02:58.644471270 +
@@ -5055,8 +5055,8 @@ indexed components, slices, and selected
@cindex @option{-gnatw.d} (@command{gcc})
If this switch is set, then warning messages are tagged, either with
the string ``@option{-gnatw?}'' showing which switch controls the warning,
-or with ``[enabled by default]'' if the warning is not under control of a
-specific @option{-gnatw?} switch. This mode is off by default, and is not
+or with ``[warning enabled by default]'' if the warning is not under control
+of a specific @option{-gnatw?} switch. This mode is off by default, and is not
affected by the use of @code{-gnatwa}.
@item -gnatw.D
Re: Use [warning enabled by default] for default warnings
IMO the natural assumption is that gnu++11 is enabled by default, which is how Lars also read it. There seemed to be support for using warning enabled by default instead, so this patch does that. Tested on x86_64-linux-gnu. OK to install? I'll post an Ada patch separately. FWIW this doesn't seem desirable to me, this will make the diagnostic longer. For Ada this wouldn't really disambiguate things, and some users may be dependent on the current format, so changing it isn't very friendly. Arno
Re: [Ada] Use [warning enabled by default] for default warnings
This switches Ada from using [enabled by default] to [warning enabled by default] for consistency with: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html Tested on x86_64-linux-gnu. OK if the above patch goes in? As I just mentioned, this isn't OK at first sight. Arno
Re: [Ada] Use [warning enabled by default] for default warnings
Robert Dewar de...@adacore.com writes: On 2/9/2014 3:03 PM, Richard Sandiford wrote: This switches Ada from using [enabled by default] to [warning enabled by default] for consistency with: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html Tested on x86_64-linux-gnu. OK if the above patch goes in? I would say hold off on this until we can find the time to coordinate updating our test suite, which we will do as fast as possible. Which testsuite do you mean? I did test this with Ada enabled and there were no regressions. If you mean an external testsuite then I certainly don't mind holding off the Ada part. I hope the non-Ada part could still go in without it though. Thanks, Richard
Re: Use [warning enabled by default] for default warnings
On 2/9/2014 3:09 PM, Arnaud Charlet wrote: IMO the natural assumption is that gnu++11 is enabled by default, which is how Lars also read it. There seemed to be support for using warning enabled by default instead, so this patch does that. Tested on x86_64-linux-gnu. OK to install? I'll post an Ada patch separately. FWIW this doesn't seem desirable to me, this will make the diagnostic longer. For Ada this wouldn't really disambiguate things, and some users may be dependent on the current format, so changing it isn't very friendly. Arno can't we just reword the one warning where there is an ambiguity to avoid the confusion, rather than creating such an earthquake, which as Arno says, really has zero advantages to Ada programmers, and clear disadvantages .. to me [enabled by default] is already awfully long!
Re: [Ada] Use [warning enabled by default] for default warnings
On 2/9/2014 3:10 PM, Richard Sandiford wrote: Which testsuite do you mean? I did test this with Ada enabled and there were no regressions. If you mean an external testsuite then I certainly don't mind holding off the Ada part. I hope the non-Ada part could still go in without it though. I mean many external test suites, many of our users maintain their own test suites, and base lines for their codes, and any change like this is very disruptive.
Re: Use [warning enabled by default] for default warnings
Robert Dewar de...@adacore.com writes: On 2/9/2014 3:09 PM, Arnaud Charlet wrote: IMO the natural assumption is that gnu++11 is enabled by default, which is how Lars also read it. There seemed to be support for using warning enabled by default instead, so this patch does that. Tested on x86_64-linux-gnu. OK to install? I'll post an Ada patch separately. FWIW this doesn't seem desirable to me, this will make the diagnostic longer. For Ada this wouldn't really disambiguate things, and some users may be dependent on the current format, so changing it isn't very friendly. Arno can't we just reword the one warning where there is an ambiguity to avoid the confusion, rather than creating such an earthquake, which as Arno says, really has zero advantages to Ada programmers, and clear disadvantages .. to me [enabled by default] is already awfully long! Well, since the Ada part has been rejected I think we just need to consider this from the non-Ada perspective. And IMO there's zero chance that each new warning will be audited for whether the [enabled by default] will be unambiguous. The fact that this particular warning caused confusion and someone actually reported it doesn't mean that there are no other warnings like that. E.g.: -fprefetch-loop-arrays is not supported with -Os [enabled by default] could also be misunderstood, especially if working on an existing codebase with an existing makefile. And the effect for: pragma simd ignored because -fcilkplus is not enabled [enabled by default] is a bit unfortunate. Those were just two examples -- I'm sure I could pick more. Thanks, Richard
Re: Use [warning enabled by default] for default warnings
On 2/9/2014 3:23 PM, Richard Sandiford wrote: can't we just reword the one warning where there is an ambiguity to avoid the confusion, rather than creating such an earthquake, which as Arno says, really has zero advantages to Ada programmers, and clear disadvantages .. to me [enabled by default] is already awfully long! Well, since the Ada part has been rejected I think we just need to consider this from the non-Ada perspective. And IMO there's zero chance that each new warning will be audited for whether the [enabled by default] will be unambiguous. The fact that this particular warning caused confusion and someone actually reported it doesn't mean that there are no other warnings like that. E.g.: -fprefetch-loop-arrays is not supported with -Os [enabled by default] could also be misunderstood, especially if working on an existing codebase with an existing makefile. And the effect for: pragma simd ignored because -fcilkplus is not enabled [enabled by default] is a bit unfortunate. Those were just two examples -- I'm sure I could pick more. Indeed, worrisome examples, a shorter substitute would be [default warning] ??? Thanks, Richard
