Bug 65801

Yes. This also breaks building Chromium.

markus@x4 ~ % echo "int main () {int i = { 0xFFFFFFFF };}" | g++ -std=c++11 -Wno-narrowing -x c++ -
<stdin>: In function ‘int main()’:
<stdin>:1:35: error: narrowing conversion of ‘4294967295u’ from ‘unsigned int’ to ‘int’ inside { }

While the standard is clear that this is an error,
accepting -Wno-narrowing as in 4.8, 4.9 and clang looks acceptable to me.

This changed with Paolo's r213776.  These examples suggest that the change to constant handling WRT -Wnarrowing was a mistake.

Ok, thus what shall we do? Shall we go back to my minimal patch which only touched enums? https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00880.html

Couldn't you simply turn the error_at into pedwarn?

Well, at the time I think we agreed that we wanted to be strict at least about enums... Otherwise, yes, we can do that plus setting ok = true in that case too, thus collapsing the last two ifs (+ reverting the docs change and adjusting the testsuite).

(In reply to Paolo Carlini from comment #5)
> Well, at the time I think we agreed that we wanted to be strict at least
> about enums... Otherwise, yes, we can do that plus setting ok = true in that
> case too, thus collapsing the last two ifs (+ reverting the docs change and
> adjusting the testsuite).

I think that for constants, we want it to be an error without -Wno-narrowing.  I wonder if the best way to get that is to set pedantic_errors around the pedwarn call?

Yes, I was thinking that in such cases clang does something we don't normally do (ie, an hard error by default suppressible with a -Wno-*). Let me see if we can achieve that as you suggested.

Jason, as far as I can see *nowhere* else in the compiler we fiddle with flag_pedantic_errors, all the tweaks I tried look super hackish to me :( If we are Ok with just going back to pedwarns the attached passes testing...

Created attachment 35367 [details]
Draft patch

I'm also attaching what I have for the forced pedantic-errors idea.

Created attachment 35370 [details]
Draft patch 2

(In reply to Paolo Carlini from comment #11)
> Draft patch 2

I think let's go with this.  It's odd, but not complex and does what we want.

Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?

(In reply to Paolo Carlini from comment #13)
> Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?

It is IMHO too late for that, but not too late for 5.2.

Author: paolo
Date: Mon Apr 20 21:46:59 2015
New Revision: 222249

URL: https://gcc.gnu.org/viewcvs?rev=222249&root=gcc&view=rev
Log:
/cp
2015-04-20  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* typeck2.c (check_narrowing): In C++11 mode too, -Wno-narrowing
	suppresses the diagnostic.

2015-04-20  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* doc/invoke.texi ([-Wnarrowing]): Update.

/testsuite
2015-04-20  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* g++.dg/cpp0x/Wnarrowing2.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing2.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck2.c
    trunk/gcc/doc/invoke.texi
    trunk/gcc/testsuite/ChangeLog

What is printed with -Wno-error=narrowing ?

(In reply to Manuel López-Ibáñez from comment #16)
> What is printed with -Wno-error=narrowing ?

Try it yourself?
Just a warning.

(In reply to Manuel López-Ibáñez from comment #16)
> What is printed with -Wno-error=narrowing ?

I'm also a bit afraid of how setting pedantic-errors in this way interacts with the #pragma GCC diagnostics. Wouldn't it be better to reclassify -Wnarrowing as an error (see diagnostic_classify_diagnostic) then simulate a #pragma GCC diagnostics pop to restore the previous state? The problem is the order in which the re-classification happens, which should appear as if it happened in the command-line and not at the point of warning, but diagnostic_classify_diagnostic assumes #pragmas are handled in the order given in the source code.

Another alternative, perhaps simpler, would be to have a different option -Wnarrowing-strict, which by default is -Werror=narrowing-strict (see Werror-implicit-function-declaration) and it is enabled by -Wnarrowing. This way, everything should work as expected (unless latent bugs in the options handling machinery for not passing the error/warning state correctly when enabling dependant options).

An even simpler options is to put this under -fpermissive so people realize that what they are doing is very wrong according to the standard (if it is not very wrong, then why error and not just pedwarn?).

(In reply to Markus Trippelsdorf from comment #17)
> (In reply to Manuel López-Ibáñez from comment #16)
> > What is printed with -Wno-error=narrowing ?
> 
> Try it yourself?
> Just a warning.

Thanks, well at least that works. I guess if someone notices a problem with the #pragmas, a better solution can be found later.

The problem with -fpermissive is that it doesn't just allow things like narrowing that are valid in C++03 but also allows all kind of ancient constructs that no sane person wants.

Author: paolo
Date: Thu Apr 30 16:31:36 2015
New Revision: 222636

URL: https://gcc.gnu.org/viewcvs?rev=222636&root=gcc&view=rev
Log:
/cp
2015-04-30  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* typeck2.c (check_narrowing): In C++11 mode too, -Wno-narrowing
	suppresses the diagnostic.

2015-04-30  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* doc/invoke.texi ([-Wnarrowing]): Update.

/testsuite
2015-04-30  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/65801
	* g++.dg/cpp0x/Wnarrowing2.C: New.

Added:
    branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/Wnarrowing2.C
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/cp/ChangeLog
    branches/gcc-5-branch/gcc/cp/typeck2.c
    branches/gcc-5-branch/gcc/doc/invoke.texi
    branches/gcc-5-branch/gcc/testsuite/ChangeLog

Fixed for 5.2 too.

Please note that narrowing conversions don't seem to work the same way they did in GCC 4.9; I've filed PR c++/66007 for this change in behavior.