In my makefile I specify -Werror=uninitialized, but no errors occur.
I changed it to -Wuninitialized, and I see my warning. -Wno-uninitialized makes it go away as expected, but why isn’t -Werror=uninitialized working?
Also it was suggested in code I write
#pragma GCC diagnostic error "-Wuninitialized"
But that does not work either. Why?
I have another question, but unfortunately none of the suggestions are working for me.
You should use -Werror. This option doesn't have any parameters (it is an on/off switch).
But it is good practice to remove all warnings, so -Werror enforces this good practice.
Related
Is there a way to enforce gcc to ignore errors which result from C++11's override?
Explanation: I want to enable C++11 in a program. Unfortunately it misused some functions and macros from a library causing many marked override, but does not override errors. So I want to disable the error, just to check if there are more issues and then replace the errors step by step.
I checked the -W options, but they handle warings only. This is a real error.
As a hack you can use -Doverride= on the command line. This will make it so GCC does not see override.
I'm trying to use ccache to speed up my rebuilds and I noticed this in the log:
[2015-04-17T10:41:45.845545 27682] Compiler option -M is unsupported
[2015-04-17T10:41:45.845584 27682] Failed; falling back to running the real compiler
In my experience you need something like the -M flag in order to have make or its equivalent trigger rebuilds correctly. It seems weird that ccache would be tripped up by an option that must be in almost every project's build. Am I missing something? Is there a more preferred option?
This is w/ ccache-3.2.1.
Edit: I tried with -MM as well, no luck.
It is correct that ccache currently doesn't support the compiler options -M and -MM (and it never has supported them).
Some reasons for why the options in question are unupported:
The options tell the compiler to let the preprocessor output make rules instead of the preprocessed source code. This is not a good match for how ccache works; it needs to get hold of the "real" preprocessed output for each compiler invocation (see https://ccache.dev/manual/3.7.11.html#_how_ccache_works).
Nobody has implemented support for the mentioned options, simply put.
It would most likely be possible to implement support by letting ccache run the compiler command twice: one without -M/-MM to retrieve the preprocessed source code (with which the result should be associated) and one with -M/-MM to retrieve the result (make rules).
However, I (speaking as the ccache maintainer for the last six years) have not heard anybody missing support for -M/-MM until now, so my impression is that -M/-MM actually aren't used much.
Am I missing something? Is there a more preferred option?
Yes, I would say that the standard way is to use -MD/-MMD (which are supported by ccache) instead of -M/-MM. -MD/-MMD are superior because they produce both the .o and the .d file in one go, whereas -M/-MM only produce the .d file, so the compiler must in that case be invoked twice by the Makefile for each source code file. See for instance http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html for how to use -MD/-MMD.
Does gcc define a macro of some sort when the flag -fprofile-generate is specified? Basically, I want to disable multithreading when I'm profiling--it seems to have a way of corrupting the .gcda files.
This unanswered question is quite old, but I was having similar issues, so I hope this can be useful to someone.
You should try enabling the -fprofile-correction GCC compiler flag when using the profile information generated by a multi-threaded application. According to the GCC documentation relative to this flag:
Profiles collected using an instrumented binary for multi-threaded programs may be inconsistent due to missed counter updates. When this option is specified, GCC uses heuristics to correct or smooth out such inconsistencies. By default, GCC emits an error message when an inconsistent profile is detected.
It will get rid of the errors indicating that the .gcda files are corrupted by correcting inconsistent profile values due to multi-threading.
With GCC and clang, I've been able to use SCons 'TryCompile' feature to build a simple configure check to determine if the currently configured compiler supports a given compile flag. Basically, clone the env, add the flag in question to CFLAGS, CCFLAGS, or CXXFLAGS, as appropriate, execute TryCompile, and if the TryCompile succeeds, then the flag is supported and we can add it to the real env.
This works perfectly with gcc, because unknown flags are errors and the compiler exits with a non-zero status.
With clang, it works reasonably well too: clang by default treats unknown errors as warnings, but if you pass it -Werror it will turn unknown flags into errors. So my wrapper around TryCompile just always passes -Werror along with the flag to be tested if it knows we are using clang.
However, this all falls over with the Microsoft toolchain because as far as I can discover, there is no way to convince the compiler to treat unknown flags as errors: they are always warnings, even if you pass the flag to make warnings errors. Since the compile exits cleanly wither or not the flag is accepted, TryCompile always succeeds. See this question for details on the various attempts I have made to get MSVC to exit with a non-zero status.
Any ideas on how I can make this work? Is there another SCons facility that I'm overlooking that can do this job for me? Should I interpose on TryCompile on MS platforms and parse the compiler output rather than examining the exit status. I'm really happy with using TryCompile for configure time flag detection with clang and gcc, but if I can't get MSVC to cooperate I'm going to need to abandon this whole approach, and I'm pretty loathe to do that since it is working so well so far.
Leave it to Windows to rain on the parade once again :) Obviously the Windows compiler always returns success, irregardless of what happens.
I can think of several options that you could try.
First of all, SCons provides a Multi-Platform Configuration (Autoconf Functionality) which may help you achieve the same result. It doesnt include anything for compiler options, but does at least includes the following:
Checking for the Existence of Header Files
Checking for the Availability of a Function
Checking for the Availability of a Library
Checking for the Availability of a typedef
Adding Your Own Custom Checks
Another option would be to build some sort of a dictionary with the Microsoft compilation options. You would probably need one dictionary per compiler version. This particular option would probably take a long time to prepare, and probably wouldnt be worth it.
Another option would be to use the Object() or Program() builder instead of the TryCompile() builder, and try to catch the failure and react accordingly. Im not sure if SCons allows you to catch compilation failures as an exception and carry on if it fails, but its worth checking into.
GCC and clang let you compile with -w to disable all warnings, but I can't see a #pragma equivalent of it. I can see only pragma support for disabling individual files.
I need this because I have code that I want to compile with high warning levels but which necessarily compiles third party code which generates arbitrary warnings.
You can kind of do it with GCC, almost, using #pragma GCC diagnostic ignored, but unluckily not very well, see here.
The problem is that you cannot just "disable all", you have to disable each single one. Plus, for some warnings it doesn't work (and the docs don't tell you which ones...).
My guess is that this somewhat preliminary and will (hopefully) be improved in the next version.