[Bug c++/69864] Fix various Wnarrowing minor issues

["egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|documentation               |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-08-24
                 CC|                            |egallager at gcc dot gnu.org
     Ever confirmed|0                           |1
           Severity|normal                      |minor

--- Comment #13 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Because int b{2.3} absolutely definitely loses precision, and since it's a
> > constant you can just fix the code.
> > 
> > For {u} the compiler doesn't know whether it really narrows or not, since it
> > depends on un time values, so it gives you the benefit of the doubt.
> 
> I updated the FAQ, but I actually agree with mgsergio that this behavior is
> inconsistent and not at all how other -Wflags behave. The fact that we have
> to do ugly kludges in the code to support this makes it only more obvious.
> 
> I'm actually going to reopen this to propose some improvements that perhaps
> someone would decide to tackle as easy hacks:
> 
> * Document that -Wnarrowing also emits errors in doc/invoke.texi
> 
> * Make the message for the error and the warning different, for example:
> 
> narrowing conversion of constant expression from 'double' to 'int' inside { }
> 
> * Do not pretty-print expressions! '2.2999999999999998e+0' is very ugly and
> I'm sure one can easily trick GCC to print absolute non-sense. That is,
> remove %qE and use proper locations/ranges.
> 
> * Create a new function in diagnostic.c, e.g., 
> 
> extern diagnostic_t pederror (location_t, int, const char *, ...)
>      ATTRIBUTE_GCC_DIAG(3,4);
> 
> and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872
> along the way). Document when some warnings might be errors (like we have
> precise definitions for permerror/pedwarn).

Documentation part is done per comment #12, but I'm still confirming that some
of these other suggestions could still be done, too.