This code: ---8<--- static struct zai { unsigned int x; } x = {-1}; --->8--- gives this error in C++11 mode: $ g++-5 -std=gnu++11 -c y.cpp y.cpp:1:46: error: narrowing conversion of ‘-1’ from ‘int’ to ‘unsigned int’ inside { } Clang 3.5 offers using -Wno-narrowing to ignore this and continue with the previous semantics of silently converting it, which is helpful if one's C++11 project has to include e.g. zend_API.h (which uses the -1 conversion). Such a feature is missing from gcc. $ gcc-5 -v gcc version 5.0.1 20150416 (prerelease) [gcc-5-branch revision 222148] (SUSE Linux)
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.