| Message ID | alpine.LNX.2.21.1703262212130.7630@anthias.pfeifer.com |
|---|---|
| State | New |
| Headers | show |
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
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.
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