-Wall -Werror are already set.
I need to add some flag to make unused-s not error but warning. -Wno-unused discards warnings at all. I want to see warning and succeed compilation. How?
I tried: -Werror=no-unused but it does not work. GCC 9.
From the GCC manual:
-Werror=
Make the specified warning into an error. The specifier for a warning is appended; for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings; for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect.
So the option you want to pass is -Wno-error=unused.
Related
I have enabled -Werror for C pre processing command to treat warnings as errors.
Basically i wanted to only treat redefined warnings as errors. And all other warnings should not be treated as errors.
In file included from /home/test/version24/test.spec:35:0,
/test/release/base_version.spec:93:0: warning: "CD_MK_FILE" redefined
#define CD_MK_FILE 4
In file included from /home/test/version23/mss_litter.spec:19:0,
from
/test/release/base_version23.spec:0: note: this is the location of the previous definition
#define CD_MK_FILE 3
Is there any flag in to treat only redefined warnings as errors.
Thank you!
How do we enable or disable specific compiler warnings or errors?
For gcc/g++ and clang compilers, try:
# To disable -Werror just for warning -Wwhatever
-Wno-error=whatever
# To **enable** errors just for this one -Wwhatever warning
-Werror=whatever
For the clang compiler, you'd use -Wno-error=macro-redefined, to disable that error for the -Wmacro-redefined warning only, and you'd use -Werror=macro-redefined to enable an error only for that warning.
See here: https://clang.llvm.org/docs/DiagnosticsReference.html#wmacro-redefined. Thanks for the comment under the question, #user3386109!
See the list of all possible warnings and errors here:
For the gcc compiler: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
For the clang compiler (which is gcc-compatible, by design): https://clang.llvm.org/docs/DiagnosticsReference.html
For example, from the gcc link above:
-Werror=
Make the specified warning into an error. The specifier for a warning is appended; for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings; for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect.
The warning message for each controllable warning includes the option that controls the warning. That option can then be used with -Werror= and -Wno-error= as described above. (Printing of the option in the warning message can be disabled using the -fno-diagnostics-show-option flag.)
Note that specifying -Werror=foo automatically implies -Wfoo. However, -Wno-error=foo does not imply anything.
Other References:
The comment by #HolyBlackCat
[my Q&A] How can I disable a C/C++ -Werror build error in Bazel? (AKA: how to turn OFF specific warnings already turned on by -Wall -Werror)
Related:
In case you ever need to control just a few lines of code, this is incredibly useful too: How to disable GCC warnings for a few lines of code
What is the meaning of -Wextra in clang compiler flag?
I was curious what does all the flags such as -Wall, -Werror means. I was able to find answers for others, but not -Wextra.
clang -Wall -Wextra -Werror
-Wextra flag is not specific to just the clang compiler, it is documented in the GCC Compiler as well. Basically, -Wall enables all (common) warning flags but this excludes many flags.
Some of these, notably -Wempty-init-stmt, -Wignored-qualifiers, -Winitializer-overrides, -Wmissing-field-initializers, -Wmissing-method-return-type, -Wnull-pointer-arithmetic, -Wsemicolon-before-method-body, -Wsign-compare, -Wunused-parameter are covered by -Wextra instead.
You can find out more about what each of these mean in the documentation.
-Wextra compiler flag is not just in clang but also in gcc. According to the gcc docs:
This enables some extra warning flags that are not enabled by -Wall. This option used to be called -W. The older name is still supported, but the newer name is more descriptive.
Source:
Clang docs
GCC docs
I have some warning when compiling a piece of code using pthread_cleanup_push/pop with -O2 CFLAGS. Just by removing the O2 cflags in the Makefile make it compile without issue.
Is it forbidden to use gcc optimization with these pthread macros ? I was not able to find anything in man or documentation. By the way, is there any alternative to clean stuff at the end of a thread ? Also it is working perfectly with gcc arm. But not on x86 gcc.
Warning :
x/x.c:1292:2: warning: variable ‘__cancel_routine’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
pthread_cleanup_push(x_cleanup, &fd);
My current CFLAGS option :
-W -Wall -Wformat -Wformat-security -Wextra -Wno-unused-result,
-Wextra -Wno-long-long -Wno-variadic-macros -Wno-missing-field-initializers
-std=gnu99 -O2
This issue has been reported several times now in GCC tracker (see here). I believe that this warns about real issue in pthread.h (see my comment). __cancel_routine is not marked as volatile so it's value is indeed undefined after return via longjmp which may cause arbitrary consequences.
The only solution is to remove the Werror until a fix ?
I'd rather go with -Wno-clobbered, to keep other warnings enabled.
Roll back on a previous version of gcc on x86 ?
You'll have to rollback to pre-2014 times which is quite a change... I think that if the code works for you, just disable -Wclobbered (with a descriptive comment).
But I did want to be sure that its was not a bigger issue which can cause unexpected behavior of my code or bugs.
Glibc code looks really suspicious. I'd wait for comments from GCC devs and if there is none, report this to Glibc developers.
We are compiling a piece of software using generics where files are first made into object files, they are built like so:
arm-unknown-linux-gnu-gcc -c -O2 -Wstrict-prototypes -Wdeclaration-after-statement -fsigned-char -I/opt/tm-sdk/include -mlittle-endian -Wno-trigraphs -fno-strict-aliasing -fno-omit-frame-pointer -march=armv4 -mtune=arm9tdmi -Wall -Wextra -o src/flex.o src/flex.c
...
arm-unknown-linux-gnu-gcc -c -O2 -Wstrict-prototypes -Wdeclaration-after-statement -fsigned-char -I/opt/tm-sdk/include -mlittle-endian -Wno-trigraphs -fno-strict-aliasing -fno-omit-frame-pointer -march=armv4 -mtune=arm9tdmi -Wall -Wextra -o src/flexdb.o src/flexdb.c
Then they are linked with:
arm-unknown-linux-gnu-gcc -o flex src/flex.o src/flexdb.o src/flexio.o src/flexprotocol.o src/flexsettings.o src/flexstate.o -L/opt/tm-sdk/lib -ltag -lrt -ltmreader -lsqlite3 -lsha1
My questions is:
Do we need to include optimization and warning flags during linking? Would it do anything if -Wall, -Wextra, and -O2 were included when creating the flex binary from the object files?
Edit: Clarifying meaning based on feedback.
Do we need to include optimization and warning flags during this final stage of compilation?
Of course you don't need to include them for the link stage. You already know that, because you don't include them. But I think what you really want to know is ...
Would it do anything if -Wall, -Wextra, and -O2 were included when building the flex binary from object files.
All or almost all warnings are generated during the compilation stage. I don't off-hand know any exceptions, but it's conceivable that there are some. Thus, it's possible that passing warning-related flags during linking would trigger warnings that otherwise you would not receive. But that shouldn't affect the compiled binary in any way.
Optimization is different. There are optimizations that can be performed at link time, but that might not be performed at the default optimization level. Omitting optimization flags from the link command should not break your build, but including them may result in a binary that is faster and / or smaller.
Overall, I see no good reason to avoid passing the same warning and optimization flags during the link step that you do during the compilation steps. If you wish, it's not harmful to pass preprocessor-specific flags (e.g. -D) as well, as they'll just be ignored during linking. I presume that all this is managed by make, so it's not like you actually need to type out the options every time.
NO You're just calling the linker with the final call to gcc and -W and -O flags are for the compiler.
-Wall is primarily a preprocessor option, but there is also a reference for the libraries. See here
-Wextra appears to be strictly a c++ preprocessor option. See here
-O2 is a compiler optimization level setting. See here
So to answer your precise question, only -Wall would possibly help during your link step. The other two would not. You could test this by building with and without these options, seeing if any additional output is created in the case of warnings and if the code size or execution time differed between builds.
What is the reason for the following kind of warning
inlining failed to while calling the function: The code size may grow.
when function is static inline.Following is a kind of function defined in header file. How can i get rid of the above mentioned warning.
static __inline___ getSomething(){
return something;
}
EDIT
yes i tried removing the inline, but i get the following warning
function getSomething defined but not used.
Is there any way to remove both the warnings?
[EDIT]
-g -Wno-unused -g -ansi -pedantic -Wall -Wshadow -Wpointer-arith -Wwrite-strings
Remove the __inline__ keyword. Compilers are generally smart enough to know when to inline, and unless you're doing detailed profiling and know better, trying to force it is unnecessary.
Is the function really not used? may be it should be removed altogether?