With gcc I can throw a bunch of -Wsome-issue and -Werror=other-issue flags on the command line and the later cancel them all with a single -w flag somewhere near the end.
This doesn't appear to be the case with clang. A trailing -w suppresses some warnings, but not others. See here for an example. I know I can manually disable each warning individually via -Wno-some-issue and -Wno-error=other-issue, but that's a real pain to manage in the long term.
Am I missing something? Is there a way to cancel all earlier warning flags? Is there a reason why -w can suppress some warnings but not others?
Background: My specific use case is a library containing a mix of source files. Some new and some ancient, semi-third-party stuff that we never want to look at, let alone edit. The project has some semi-strict warning flags set globally, but for these few files I'd like to override the global flags and disable all warnings and warnings-as-werrors. In CMake this is done by settings the COMPILE_OPTIONS property for those files, which appends the given flags after the global flags. With gcc this works just fine, but with clang it's proving to be a headache.
(And yes I know I could reorganise the project to force those files to be compiled into a separate target, but I was hoping to avoid that.)
The flag you need is -Wno-everything.
Godbolt: https://godbolt.org/g/33uABD
Related
When invoking ninja on a C or C++ (hence both tags) project, with the clang or gcc compiler, the output is not colored with ANSI colors.
For example:
error should be red, but isn't.
warning should be yellow/orange, but isn't.
Everything is the same color, and it's really hard to tell what's going on!
Why this happens
This happens because ninja internally creates a pipe(), which stdout and stderr from the compiler (gcc or clang in this case) is re-routed. This makes the check inside gcc and clang, which checks for terminals (which may support color), fail.
A check such as isatty(stdout) does not return true for a pipe, even though that pipe is then forwarded to stdout once again.
It's documented
Ninja's FAQ talks about this on GitHub.com, but this FAQ is not included with the software, not mentioned in the --help, there are no ninja manpages, and common search engines (ddg, google) do not seem to find that FAQ for common search queries relating to color.
Hence, this post, since SO has good SSO.
The fix
Add -fdiagnostics-color=always to your C or CXX flags. For example, with cmake, you can append -DCMAKE_CXX_FLAGS=-fdiagnostics-color=always (or CMAKE_C_FLAGS for C) (or, if you are using CMake 3.24 or later, you can use the CMAKE_COLOR_DIAGNOSTICS variable or environment variable).
This works for gcc (as documented in its manpage) and clang (clang's manpages do not mention this option, but it is included in their command line reference on llvm.org.
As a permanent fix, you could append the following to your .zshrc, .bashrc, or similar:
# force C colored diagnostic output
export CFLAGS="${CFLAGS} -fdiagnostics-color=always"
# force C++ colored diagnostic output
export CXXFLAGS="${CXXFLAGS} -fdiagnostics-color=always"
export CCFLAGS="${CCFLAGS} -fdiagnostics-color=always"
# force C, C++, Cpp (pre-processor) colored diagnostic output
export CPPFLAGS="${CPPFLAGS} -fdiagnostics-color=always"
You should only do this if you KNOW you will never need to pipe your compiler's output anywhere else. Also, this will only work with clang and gcc, and other compilers which support this - so make sure you dont use compilers that choke on this flag.
I am attempting to compile a C++ library for a Tegra TK1. The library links to TBB, which I pulled using the package manager. During compilation I got the following error
/tmp/cc4iLbKz.s: Assembler messages:
/tmp/cc4iLbKz.s:9541: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r3,[r4]'
A bit of googling and this question led me to try adding -mimplicit-it=thumb to CMAKE_CXX_FLAGS, but the compiler doesn't recognize it.
I am compiling on the tegra with kernal 3.10.40-grinch-21.3.4, and using gcc 4.8.4 compiler (thats what comes back when I type c++ -v)
I'm not sure what the initial error message means, though I think it has something to do with the TBB linked library rather than the source I'm compiling. The problem with the fix is also mysterious. Can anyone shed some light on this?
-mimplicit-it is an option to the assembler, not to the compiler. Thus, in the absence of specific assembler flags in your makefile (which you probably don't have, given that you don't appear to be using a separate assembler step), you'll need to use the -Wa option to the compiler to pass it through, i.e. -Wa,-mimplicit-it=thumb.
The source of the issue is almost certainly some inline assembly - possibly from a static inline in a header file if you're really only linking pre-built libraries - which contains conditionally-executed instructions (I'm going to guess its something like a cmpxchg implementation). Since your toolchain could well be configured to compile to the Thumb instruction set - which requires a preceding it (If-Then) instruction to set up conditional instructions - by default, another alternative might be to just compile with -marm (and/or remove -mthumb if appropriate) and sidestep the issue by not using Thumb at all.
Adding compiler option:
-wa
should solve the problem.
I am trying to eliminate the warnings in my project so I can turn on the flag that treats warnings as errors. The project uses the boost library, specifically the Concept_check.hpp and cuthill_mckee_ordering.hpp files. The warnings 4510 and 4610 are shown in the concept_check.hpp file and I have tried to disable them using #pragma warning push and pop. The warnings are caused by the boost library trying to instantiate a class using the template found in concept_check.cpp when there is no constructor written for it.
My Question is this: Is there a more sure fire way that I can disable these warnings without modifying the boost code? I am using Visual studio 2010.
Perhaps you are looking in the wrong direction. As Alan Stokes pointed out, the warning is there for a reason. I have three hints that are perhaps not the answers you expect, but may bring an acceptable solution:
Instead of silencing the warning, just fix the error. I don't know your code, but there are other people that had a similar problem which was possible to fix by just declaring a variable.
Another question is: why do you want to turn all your warnings into errors? Is it really neccessary? I agree that normal code should always compile without warnings. But these warnings are not originating from your own code. Consider a static code-checker that warns you about issues where your compiler is blind about.
If you have to use -WX, move the offending code into a static object/library/module so you will be bothered about the warning only when you need to recompile this module. You could use specific compile options for this module, to get the warnings completely out of your way.
There is another possibility, but I'm not able to check whether it really works. According the Microsoft Documentation it is possible to set the warning level of specific warnings. (there are similar options for GCC). First, switch all warnings to error:
/WX
Then, set the warning level of the two offending warnings to zero:
/W04510 /W04610
A complete commandline would look like this:
cl source.cpp /WX /W04510 /W04610
The best solution would be to combine this with hint 3 above. This way, the specific compiler options are only used for the files that cause the warnings.
Maybe these solutions work.
You can disable specific warning from a .h file (#pragma warning( disable: ... ).
For example, gcc 4.7 has a new feature -Wnarrowing. In configure.ac, how can I test where a feature is supported by the current gcc or not?
There's a file in gnulibc, but doesn't make much sense to me.
Both gcc and clang support -W[no-]narrowing and -W[no-]error=narrowing options.
With -std=c++11, gcc emits a warning by default, and clang emits an error by default. Even though you only mention gcc, I think you could extend the functionality check to compilers like clang that attempt to provide the same options and extensions. That might include Intel's icc too.
Let's assume you've selected the C++ compiler with AC_PROG_CXX, and have ensured that it's using the C++11 standard.
ac_save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -Werror -Wno-error=narrowing"
AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],
[[int i {1.0}; (void) i;]])],
[ac_cxx_warn_narrowing=1], [ac_cxx_warn_narrowing=0])
AS_IF([test $ac_cxx_warn_narrowing -ne 0],
[AC_MSG_RESULT(['$CXX' supports -Wnarrowing])])
AC_LANG_POP([C++])
CXXFLAGS="$ac_save_CXXFLAGS"
Compilation will only succeed if: 1) the compiler supports -Wnarrowing related options, which implies it supports -Werror, and: 2) recognizes C++11 initialization syntax.
Normally, configure.ac scripts and flags passed to configure should avoid -Werror, as it breaks too many internal tests. In this context, we ensure there are no other warnings besides the narrowing, which is why (void) i; is needed to prevent a warning about unused variables.
The logic behind this should probably be:
Create a correct file that should get a warning with -Wnarrowing. Verify that it gets compiled correctly. This is a sanity check.
Then compile that same file with -Wnarrowing, and verify that it still gets compiled correctly. This makes sure you detect compilers that don't support -Wnarrowing as an option, and don't attempt to pass bogus options to them.
Finally, compile that same file with -Werror=narrowing, and verify that it now does not get compiled correctly. If it now fails, you can be fairly certain that the compiler does indeed support -Wnarrowing. This last check is useful to detect compilers that do accept -Wnarrowing/-Werror=narrowing, but spit out a warning "ignoring unknown option -Wnarrowing". In that case, you shouldn't be passing -Wnarrowing.
Optionally, you may also want to compile a file that shouldn't get a warning with -Wnarrowing with -Werror=narrowing, in case you find a compiler where -Wnarrowing is useless and -Werror=narrowing is a hard error. I cannot think of a compiler where this would be required, though.
Translating this to a configure check should be trivial.
See http://code.google.com/p/opendoom/source/browse/trunk/VisualC8/autotools/ac_c_compile_flags.m4 for an example test of this sort - this tries to compile a trivial program with the given compiler flag, and adds it to CFLAGS if it works.
An example: I'm using -Wall -Werror and -Werror. This means unused static functions break the build. Clearly (?) unused functions are Bad, but if I'm working on code and it's in an intermediate state, want to be able to leave unused code in there. I can turn off the error with -Wno-unused-function, but then there's a risk that I'll finish what I'm working on, commit the code, and forget to remove the now-unused function.
How can I set all warnings to errors with -Wall, but downgrade specific errors to warnings, without disabling them completely?
Use the -Wno-error= flags. In the example, the required flag would be -Wno-error=unused-function.
PS: There are also pragmas for this purpose: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html (my original question was "How can I do what these pragmas do, but in the command-line flags?" but I worked it out as I was asking it).