[Bug other/53313] New: Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Bug #: 53313 Summary: Add warning levels Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: deusexsophism...@gmail.com The mailing list recently had this thread: http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html A separate, but I think possibly more important issue came up in that thread, starting at this post: http://gcc.gnu.org/ml/gcc/2012-04/msg00395.html Vincent Lefevre mentioned the idea of warnings levels. So instead of saying gcc -Wall -Wextra you would say gcc -W3 (or something). This is similar to what we do now for optimization levels and debug levels (-gn, -On), but there are a few things that I would like to do differently. First of all, I would have these warnings be entirely meta-warnings. They would only turn on other warning flags. This means that unlike -02, where it turns on some optimizations not enabled by any flag, you could synthesize -W2 by selectively turning on every single warning contained by it. In fact, I believe that all warnings should fall into one of two categories: either they warn for exactly one thing, or they are a collection of warnings. As an example of what I feel should be changed, consider this enhancement request: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651 . -Wextra turns on a few options that are specified by other flags, but it also turns on a few warnings that don't seem to be part of any warning flag. As another example of where this might be helpful, C++ developers have the option Weffc++. It has 7 warnings, some of which appear to be turned on by other warnings (but not all). However, I personally do not use it because one of the 7 warnings it turns on has too many false positives for my code, so I cannot take advantage of the other 6 and still compile with Werror. If Weffc++ were entirely a meta-option, I could turn it on, and then disable that one warning. However, I feel the best solution is the one mentioned in that thread: warning levels. Every warning level would include all of the warnings on the level below. I did a bit of research on the warning levels, and the results of it were posted here: http://stackoverflow.com/questions/5088460/flags-to-enable-thorough-and-verbose-g-warnings/9862800#9862800 This is a rough outline for what I feel the levels should be: -W0: Absolutely no warnings at all. -W1: Warnings that almost never false positive. The discussion on the mailing list seemed to suggest that this would be roughly equivalent to -Wall -Wno-unused -Wno-unitialized. This would likely be the default warning level. -W2: I'm not exactly sure what the guiding principle would be for warnings higher than -W1. My guess would simply be making a judgment call on the ratio of real warnings : false positives, or else entirely based on the number of false positives. For W2 specifically, it would likely be equivalent to -Wall -Wextra. That's a pretty common set of warnings that I see people using, and has a low level of false-positive. I could see a strong argument for making this the default instead of -W1, but either would be a nice improvement. I would probably also add -Winvalid-pch because even though it's unlikely to trigger, if it does, it will generally indicate something is wrong (assuming the user is actually using a pre-compiled header). -W3: A high level of warning. False positives are still tried to avoid, but we could allow style guidelines to be at this level. I suggest something roughly equivalent to: -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wstrict-null-sentinel -Wstrict-overflow=5 -Wundef -Wuseless-cast -Wzero-as-null-pointer-constant. Some of the warnings in -Weffc++ could be added here if it were split into multiple warnings. This is the set of warnings that I actually recommend for everyone to add in my StackOverflow posting, with a few of the questionable warnings that are present removed from the list. -W4: A paranoid level of warning. Likely equivalent to -W3 -Wdisabled-optimization -Wsign-conversion -Wsign-promo -Wstack-protector -Wswitch-default. This is every warning that I recommend turning on in my StackOverflow posting, plus a few that I didn't have just because they are likely to do nothing at all for most users and I didn't want them cluttering the command line even more, but if they are all hiding behind -W4, it won't matter. -W5: I would define this one currently as all the warnings, but it does not necessarily need to always be this. False-positives are not considered for inclusion in this list. It would be (as far as I can tell) -W4 -Wabi
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #1 from David Stone DeusExSophismata at gmail dot com 2012-05-10 22:00:17 UTC --- We could also consider deprecating -Wall and -Wextra in favor of the numbered warnings, but that obviously is not required.
[Bug other/53316] New: Change -O1 to be easily debugged and on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 Bug #: 53316 Summary: Change -O1 to be easily debugged and on by default Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: deusexsophism...@gmail.com The definition of -O1 is currently based on optimizations that are quick to do (focused on minimizing compile time). However, in the -Wall by default thread, people discussed changing the semantics / defaults of optimization. http://gcc.gnu.org/ml/gcc/2012-04/msg00134.html In particular, this post was interesting: http://gcc.gnu.org/ml/gcc/2012-04/msg00181.html The suggestion is to change -O1 to instead be optimizations that do not interfere with debugging. I was especially interested in the claim by Richard Guenther: I'd expect compile time that should be better or at least not a lot slower than -O0. Basically, that a few optimizations that remove some of the cruft from code could actually speed up later stages of compilation, so we could get faster programs that also compile faster (or at the very least, at a similar speed). This would make it easier to debug applications that rely on optimizations to run at reasonable speeds. -O2 and -O3 could maintain their current definition. It would then be possible to turn this on by default with few (if any) negative consequences, because debugging is not impaired, compile-time likely won't be increased by much (if at all), and run-time performance will be improved. This would also improve the effectiveness of certain warnings. Robert Dewar proposed a two-phase approach. First, we create a new, experimental optimization level to see if we actually can find a set of optimizations that do not interfere with debugging and do not significantly slow compilation. Then we change O1 to mean this optimization level. This way we are separating production levels from experimental levels. We could temporarily call the new level something like -Odebug or -Og. As it stands, does anyone even use -O1? It seems like it would be a major improvement to make it useful.
[Bug other/53316] Change -O1 to be easily debugged and on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 David Stone DeusExSophismata at gmail dot com changed: What|Removed |Added CC||DeusExSophismata at gmail ||dot com --- Comment #2 from David Stone DeusExSophismata at gmail dot com 2012-05-10 23:28:57 UTC --- (In reply to comment #1) I think this is not a good idea I think I explained the potential gains already. What are the potential harms? Why is it not a good idea?
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
David Stone DeusExSophismata at gmail dot com changed:
What|Removed |Added
CC||DeusExSophismata at gmail
||dot com
--- Comment #10 from David Stone DeusExSophismata at gmail dot com 2012-03-24
06:52:04 UTC ---
Simple self-contained test case:
unsigned f (int x) {
return (x = 0) ? x : -x;
}
int main () {
return 0;
}
It seems like we could at least add a simple improvement that just checks for
simple comparisons to 0. That probably catches most code (I often do one set of
calculations for non-negative values, and another set for negative values) and
avoids a lot of problems of trying to track complex calculations for the
signedness of the result. I wouldn't be perfect, but it would be better than it
currently is.
Being able to detect cases like this is also an optimization opportunity,
because division with positive integers is simpler than division with negative
integers, for example. We could reuse code that detects that optimization
opportunity for this warning.
[Bug c++/52703] New: -Wsign-conversion warns for unsigned short promoted to int and assigned to unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52703
Bug #: 52703
Summary: -Wsign-conversion warns for unsigned short promoted to
int and assigned to unsigned
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
$ g++ test.cpp -Wsign-conversion
test.cpp: In function ‘int main()’:
test.cpp:7:19: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
test.cpp:8:10: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
unsigned f (unsigned x) {
return x;
}
int main () {
unsigned short a = 0;
unsigned b = a + 1;
f (a + 1);
return 0;
}
The implicit conversion to int from unsigned short causes gcc to think that the
result of a + 1 could theoretically be a negative value (since it's an int).
However, it cannot be no matter what value a has (since we know it's unsigned).
signed overflow is undefined, so we don't have to worry about a + (integral
constant expression) INT_MAX.
Note that the bug does not trigger if + 1 is replaced with + 0. My guess is
that the removal of addition by 0 happens before this warning is checked. It
also does not trigger if a is declared `unsigned short const` instead of just
`unsigned short`.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752 --- Comment #21 from David Stone DeusExSophismata at gmail dot com 2012-03-24 21:25:08 UTC --- Why was this patch rejected, and is there a way to improve it so that obviously safe cases (such as PR52703) are not warned about without having to specify a '-Wno-' option? Yes, according to the standard (C++03 5/9), calculations done on variables smaller than int are first promoted to int, then the calculation is done, then the value is converted back to the target size. However, C++03 1.8/3, the as-if rule, states that it the program can't tell the difference, you can do whatever you want (see my answer to a similar question on Stack Overflow here: http://stackoverflow.com/questions/5563000/implicit-type-conversion-rules-in-c-operators/8935697#8935697). The C++ standard does not require a diagnostic for this, and the apparent behavior is identical. Therefore, there can be no appeals to the C++ standard on the behavior of the warning. Because this is a purely option warning for which gcc defines the rules, we should define it to be useful. If gcc can prove that all of the values are greater than 0 (for instance, if all of the values are unsigned prior to implicit promotion or are positive integral constant expressions), then there is no possibility of having a negative value. Thanks to signed integer overflow being undefined, there is no risk of creating a negative value that way, either. Therefore, we should not warn. Having to manually say Turn off stuff that no one could ever possibly want to see seems like a sure way to make this warning useless.
[Bug c++/52697] New: -Wsign-conversion warns for obviously correct code with implicit promotion to int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52697
Bug #: 52697
Summary: -Wsign-conversion warns for obviously correct code
with implicit promotion to int
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
// test.cpp
unsigned f (unsigned short a) {
return (a) ? a : 0;
}
int main () {
return 0;
}
// command line
$ g++ test.cpp -Wsign-conversion
test.cpp: In function ‘unsigned int f(int)’:
test.cpp:2:25: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
What I find interesting is the wide array of code that does not trigger a
warning. None of the following definitions of f() cause a warning:
unsigned f (unsigned short a) {
return (a) ? a : a;
}
unsigned f (unsigned short a) {
return (a) ? a : 0u;
}
unsigned f (unsigned short a) {
return (true) ? a : 0;
}
unsigned f (unsigned short a) {
return (false) ? a : 0;
}
It seems that there is some sort of error in the implicit conversion to int for
certain types of arithmetic.
This may be related to PR 38470
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470)
[Bug c++/52308] New: -pedantic -ffast-math fails to compile with cmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52308
Bug #: 52308
Summary: -pedantic -ffast-math fails to compile with cmath
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
[david@david-desktop ~]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
The following program fails to compile if given the flags -ffast-math
-pedantic.
#include cmath
int main () {
return 0;
}
[david@david-desktop ~]$ g++ test.cpp -pedantic -ffast-math
In file included from /usr/include/math.h:423:0,
from
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/cmath:46,
from test.cpp:1:
/usr/include/bits/math-finite.h:25:53: error: declaration of ‘double
acos(double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:55:1: error: from previous declaration ‘double
acos(double) throw ()’
/usr/include/bits/math-finite.h:26:53: error: declaration of ‘float
acosf(float)’ has a different exception specifier
/usr/include/bits/mathcalls.h:55:1: error: from previous declaration ‘float
acosf(float) throw ()’
/usr/include/bits/math-finite.h:28:65: error: declaration of ‘long double
acosl(long double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:55:1: error: from previous declaration ‘long
double acosl(long double) throw ()’
/usr/include/bits/math-finite.h:33:55: error: declaration of ‘double
acosh(double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:89:1: error: from previous declaration ‘double
acosh(double) throw ()’
/usr/include/bits/math-finite.h:34:55: error: declaration of ‘float
acoshf(float)’ has a different exception specifier
/usr/include/bits/mathcalls.h:89:1: error: from previous declaration ‘float
acoshf(float) throw ()’
/usr/include/bits/math-finite.h:36:67: error: declaration of ‘long double
acoshl(long double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:89:1: error: from previous declaration ‘long
double acoshl(long double) throw ()’
/usr/include/bits/math-finite.h:41:53: error: declaration of ‘double
asin(double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:57:1: error: from previous declaration ‘double
asin(double) throw ()’
/usr/include/bits/math-finite.h:42:53: error: declaration of ‘float
asinf(float)’ has a different exception specifier
/usr/include/bits/mathcalls.h:57:1: error: from previous declaration ‘float
asinf(float) throw ()’
/usr/include/bits/math-finite.h:44:65: error: declaration of ‘long double
asinl(long double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:57:1: error: from previous declaration ‘long
double asinl(long double) throw ()’
/usr/include/bits/math-finite.h:48:63: error: declaration of ‘double
atan2(double, double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:61:1: error: from previous declaration ‘double
atan2(double, double) throw ()’
/usr/include/bits/math-finite.h:49:62: error: declaration of ‘float
atan2f(float, float)’ has a different exception specifier
/usr/include/bits/mathcalls.h:61:1: error: from previous declaration ‘float
atan2f(float, float) throw ()’
/usr/include/bits/math-finite.h:51:80: error: declaration of ‘long double
atan2l(long double, long double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:61:1: error: from previous declaration ‘long
double atan2l(long double, long double) throw ()’
/usr/include/bits/math-finite.h:56:55: error: declaration of ‘double
atanh(double)’ has a different exception specifier
/usr/include/bits/mathcalls.h:93:1: error: from previous declaration ‘double
atanh(double) throw ()’
/usr/include/bits/math-finite.h:57:55: error: declaration of ‘float
atanhf(float)’ has a different exception specifier
/usr/include/bits/mathcalls.h:93:1: error: from previous declaration ‘float
atanhf(float)
[Bug lto/51806] New: -flto ignores -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51806
Bug #: 51806
Summary: -flto ignores -Werror
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
If a program triggers a warning that is only discovered during link time
optimization (such as a potential use of an uninitialized variable that crosses
compilation unit boundaries), the flag -Werror is ignored.
[david@david-desktop gcc error]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
==
main.cpp
==
void f1 (int x);
int main () {
int x;
f1 (x);
return 0;
}
==
werror.cpp
==
void f1 (int x) {
volatile int y = x;
}
==
[david@david-desktop gcc error]$ g++ main.cpp werror.cpp -Wuninitialized
-Werror -O1 -flto
In file included from :0:0:
main.cpp: In function ‘main’:
werror.cpp:2:19: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
main.cpp:4:6: note: ‘x’ was declared here
Compilation is seen as successful and a.out exists.
The expected behavior is that the warning would be converted to an error by
-Werror and stop the linking / compiling final stage. The effect of this is
that automated build tools believe that the compiling was a success (and the
warning may be buried deep in the middle of the output when compiling multiple
programs), so the user may not know that there was a problem found despite
having -Werror selected.
