[patch] Clarify interaction of -Wnarrowing with -std

[patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.

I think the right way to do that is clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all later modes (not just
with -std=c++11 as it says now), narrowing conversions produce errors
or warnings by default.

OK for trunk?



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1720 bytes --]

commit b78b2728d8d946bd92843f6155cdd2415682da09
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Feb 19 12:14:33 2016 +0000

    	* doc/invoke.texi (C++ Dialect Options): Clarify interaction of
    	-Wnarrowing with -std.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2bd793d..c1ab788 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2756,7 +2756,8 @@ Requires @option{-flto} to be enabled.  Enabled by default.
 @item -Wnarrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-Warn when a narrowing conversion prohibited by C++11 occurs within
+With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
 @smallexample
@@ -2765,10 +2766,13 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-With @option{-std=c++11}, @option{-Wno-narrowing} suppresses the diagnostic
-required by the standard.  Note that this does not affect the meaning
-of well-formed code; narrowing conversions are still considered
-ill-formed in SFINAE context.
+When a later standard is in effect, e.g. when using @option{-std=c++11},
+narrowing conversions are diagnosed by default, as required by the standard.
+A narrowing conversion from a constant produces an error,
+and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
 
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jason Merrill]

On 02/19/2016 07:42 AM, Jonathan Wakely wrote:
> In PR69864 Manu suggests improving the docs to explain that
> -Wnarrowing sometimes produces errors not warnings.
>
> I think the right way to do that is clarify how it interacts with
> -std. Specifically that the effect of -Wnarrowing listed first in the
> manual *only* applies to C++98 modes, For all later modes (not just
> with -std=c++11 as it says now), narrowing conversions produce errors
> or warnings by default.
>
> OK for trunk?

OK, thanks.

Jason

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Sandra Loosemore]

On 02/19/2016 12:01 PM, Jason Merrill wrote:
> On 02/19/2016 07:42 AM, Jonathan Wakely wrote:
>> In PR69864 Manu suggests improving the docs to explain that
>> -Wnarrowing sometimes produces errors not warnings.
>>
>> I think the right way to do that is clarify how it interacts with
>> -std. Specifically that the effect of -Wnarrowing listed first in the
>> manual *only* applies to C++98 modes, For all later modes (not just
>> with -std=c++11 as it says now), narrowing conversions produce errors
>> or warnings by default.
>>
>> OK for trunk?
>
> OK, thanks.

I suppose the patch is OK as it stands, but I was going to suggest 
restructuring it so that it talks about the default behavior first and 
what it does with non-default -std= options after that, instead of 
vice-versa.  Unfortunately I am backlogged on other things right now and 
it might take me a day or two before I have time to come up with some 
alternate wording.  If we are in a rush, go ahead and commit the 
existing patch meanwhile, I guess.

-Sandra

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>On 02/19/2016 12:01 PM, Jason Merrill wrote:
>>On 02/19/2016 07:42 AM, Jonathan Wakely wrote:
>>>In PR69864 Manu suggests improving the docs to explain that
>>>-Wnarrowing sometimes produces errors not warnings.
>>>
>>>I think the right way to do that is clarify how it interacts with
>>>-std. Specifically that the effect of -Wnarrowing listed first in the
>>>manual *only* applies to C++98 modes, For all later modes (not just
>>>with -std=c++11 as it says now), narrowing conversions produce errors
>>>or warnings by default.
>>>
>>>OK for trunk?
>>
>>OK, thanks.
>
>I suppose the patch is OK as it stands, but I was going to suggest 
>restructuring it so that it talks about the default behavior first and 
>what it does with non-default -std= options after that, instead of 
>vice-versa.  Unfortunately I am backlogged on other things right now 
>and it might take me a day or two before I have time to come up with 
>some alternate wording.  If we are in a rush, go ahead and commit the 
>existing patch meanwhile, I guess.

I did wonder about that but couldn't come up with wording I liked.

I went ahead and committed it after Jason's OK, but I can take another
look at it next week.

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>On 02/19/2016 12:01 PM, Jason Merrill wrote:
>>On 02/19/2016 07:42 AM, Jonathan Wakely wrote:
>>>In PR69864 Manu suggests improving the docs to explain that
>>>-Wnarrowing sometimes produces errors not warnings.
>>>
>>>I think the right way to do that is clarify how it interacts with
>>>-std. Specifically that the effect of -Wnarrowing listed first in the
>>>manual *only* applies to C++98 modes, For all later modes (not just
>>>with -std=c++11 as it says now), narrowing conversions produce errors
>>>or warnings by default.
>>>
>>>OK for trunk?
>>
>>OK, thanks.
>
>I suppose the patch is OK as it stands, but I was going to suggest 
>restructuring it so that it talks about the default behavior first and 
>what it does with non-default -std= options after that, instead of 
>vice-versa.  Unfortunately I am backlogged on other things right now 
>and it might take me a day or two before I have time to come up with 
>some alternate wording.  If we are in a rush, go ahead and commit the 
>existing patch meanwhile, I guess.

Is this better?



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1857 bytes --]

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 490df93..8d56efa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2753,10 +2753,17 @@ During the link-time optimization warn about type mismatches in
 global declarations from different compilation units.
 Requires @option{-flto} to be enabled.  Enabled by default.
 
-@item -Wnarrowing @r{(C++ and Objective-C++ only)}
+@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+For C++11 and later standards, narrowing conversions are diagnosed by default,
+as required by the standard.  A narrowing conversion from a constant produces
+an error, and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
+
+With @option{-Wnarrowing} in C++98, warn when a narrowing
 conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
@@ -2766,14 +2773,6 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-When a later standard is in effect, e.g. when using @option{-std=c++11},
-narrowing conversions are diagnosed by default, as required by the standard.
-A narrowing conversion from a constant produces an error,
-and a narrowing conversion from a non-constant produces a warning,
-but @option{-Wno-narrowing} suppresses the diagnostic.
-Note that this does not affect the meaning of well-formed code;
-narrowing conversions are still considered ill-formed in SFINAE contexts.
-
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept
 @opindex Wno-noexcept

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Gerald Pfeifer]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Hi Jonathan,

On Tue, 23 Feb 2016, Jonathan Wakely wrote:
> On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>> I suppose the patch is OK as it stands, but I was going to suggest
>> restructuring it so that it talks about the default behavior first and what
>> it does with non-default -std= options after that, instead of vice-versa.
>> Unfortunately I am backlogged on other things right now and it might take me
>> a day or two before I have time to come up with some alternate wording.  If
>> we are in a rush, go ahead and commit the existing patch meanwhile, I guess.
> Is this better?

I believe your follow-up patch did not get committed, nor did I
see any response from anyone.

To me it looks fine.  Did you hold of intentionally, or did this
get lost for lack of responses?

Sandra, what do you think?

Gerald

[-- Attachment #2: Type: text/x-patch, Size: 1857 bytes --]

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 490df93..8d56efa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2753,10 +2753,17 @@ During the link-time optimization warn about type mismatches in
 global declarations from different compilation units.
 Requires @option{-flto} to be enabled.  Enabled by default.
 
-@item -Wnarrowing @r{(C++ and Objective-C++ only)}
+@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+For C++11 and later standards, narrowing conversions are diagnosed by default,
+as required by the standard.  A narrowing conversion from a constant produces
+an error, and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
+
+With @option{-Wnarrowing} in C++98, warn when a narrowing
 conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
@@ -2766,14 +2773,6 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-When a later standard is in effect, e.g. when using @option{-std=c++11},
-narrowing conversions are diagnosed by default, as required by the standard.
-A narrowing conversion from a constant produces an error,
-and a narrowing conversion from a non-constant produces a warning,
-but @option{-Wno-narrowing} suppresses the diagnostic.
-Note that this does not affect the meaning of well-formed code;
-narrowing conversions are still considered ill-formed in SFINAE contexts.
-
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept
 @opindex Wno-noexcept

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Sandra Loosemore]

On 03/26/2017 02:13 PM, Gerald Pfeifer wrote:
> Hi Jonathan,
>
> On Tue, 23 Feb 2016, Jonathan Wakely wrote:
>> On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>>> I suppose the patch is OK as it stands, but I was going to suggest
>>> restructuring it so that it talks about the default behavior first
>>> and what
>>> it does with non-default -std= options after that, instead of
>>> vice-versa.
>>> Unfortunately I am backlogged on other things right now and it might
>>> take me
>>> a day or two before I have time to come up with some alternate
>>> wording.  If
>>> we are in a rush, go ahead and commit the existing patch meanwhile, I
>>> guess.
>> Is this better?
>
> I believe your follow-up patch did not get committed, nor did I
> see any response from anyone.
>
> To me it looks fine.  Did you hold of intentionally, or did this
> get lost for lack of responses?
>
> Sandra, what do you think?

Looks OK to me.  I apologize for losing track of this patch previously.  :-(

-Sandra

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 26/03/17 14:32 -0600, Sandra Loosemore wrote:
>On 03/26/2017 02:13 PM, Gerald Pfeifer wrote:
>>Hi Jonathan,
>>
>>On Tue, 23 Feb 2016, Jonathan Wakely wrote:
>>>On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>>>>I suppose the patch is OK as it stands, but I was going to suggest
>>>>restructuring it so that it talks about the default behavior first
>>>>and what
>>>>it does with non-default -std= options after that, instead of
>>>>vice-versa.
>>>>Unfortunately I am backlogged on other things right now and it might
>>>>take me
>>>>a day or two before I have time to come up with some alternate
>>>>wording.  If
>>>>we are in a rush, go ahead and commit the existing patch meanwhile, I
>>>>guess.
>>>Is this better?
>>
>>I believe your follow-up patch did not get committed, nor did I
>>see any response from anyone.
>>
>>To me it looks fine.  Did you hold of intentionally, or did this
>>get lost for lack of responses?
>>
>>Sandra, what do you think?
>
>Looks OK to me.  I apologize for losing track of this patch previously.  :-(

OK, thanks, I'll commit it today.

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On 27/03/17 10:09 +0100, Jonathan Wakely wrote:
>On 26/03/17 14:32 -0600, Sandra Loosemore wrote:
>>On 03/26/2017 02:13 PM, Gerald Pfeifer wrote:
>>>Hi Jonathan,
>>>
>>>On Tue, 23 Feb 2016, Jonathan Wakely wrote:
>>>>On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
>>>>>I suppose the patch is OK as it stands, but I was going to suggest
>>>>>restructuring it so that it talks about the default behavior first
>>>>>and what
>>>>>it does with non-default -std= options after that, instead of
>>>>>vice-versa.
>>>>>Unfortunately I am backlogged on other things right now and it might
>>>>>take me
>>>>>a day or two before I have time to come up with some alternate
>>>>>wording.  If
>>>>>we are in a rush, go ahead and commit the existing patch meanwhile, I
>>>>>guess.
>>>>Is this better?
>>>
>>>I believe your follow-up patch did not get committed, nor did I
>>>see any response from anyone.
>>>
>>>To me it looks fine.  Did you hold of intentionally, or did this
>>>get lost for lack of responses?
>>>
>>>Sandra, what do you think?
>>
>>Looks OK to me.  I apologize for losing track of this patch previously.  :-(
>
>OK, thanks, I'll commit it today.

I've committed the attached patch.



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 2133 bytes --]

commit 77d4b96ba46e57a761e6844b89de9412011ef583
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Mar 27 19:37:01 2017 +0100

    Restructure -Wno-narrowing documentation
    
    	* doc/invoke.texi (-Wno-narrowing): Reorder so default behavior is
    	covered first.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3f0eb2f..8d3821e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2869,10 +2869,17 @@ During the link-time optimization warn about type mismatches in
 global declarations from different compilation units.
 Requires @option{-flto} to be enabled.  Enabled by default.
 
-@item -Wnarrowing @r{(C++ and Objective-C++ only)}
+@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+For C++11 and later standards, narrowing conversions are diagnosed by default,
+as required by the standard.  A narrowing conversion from a constant produces
+an error, and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
+
+With @option{-Wnarrowing} in C++98, warn when a narrowing
 conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
@@ -2882,14 +2889,6 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-When a later standard is in effect, e.g. when using @option{-std=c++11},
-narrowing conversions are diagnosed by default, as required by the standard.
-A narrowing conversion from a constant produces an error,
-and a narrowing conversion from a non-constant produces a warning,
-but @option{-Wno-narrowing} suppresses the diagnostic.
-Note that this does not affect the meaning of well-formed code;
-narrowing conversions are still considered ill-formed in SFINAE contexts.
-
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept
 @opindex Wno-noexcept