I am trying to compile some C code in Linux Kernel.
I have a huge project that compiles without any warnings. The compilation line is very very long and complex.
In project, the compiler did not warn about variables that are part of the function signature that were not used (even though it contains flags such as -Wall). such as:
void foo (int a) {
}
I cannot see why it would not warn on it.
So i checked the actual compilation lines on the original project by running:
make -n
It does not have the flag -Wno-unused-parameter that cancels this warning.
Does anyone know of a flag that cancels this warning? Maybe a different flag that contains the -Wno-unused-parameter flag ?
Thanks
Matt
According to Warning Options - Using the GNU Compiler Collection (GCC), -Wall doesn't enable -Wunused-parameter, so this warning isn't mysteriously cancelled, but simply not enabled.
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
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.
I know that if you execute GCC as such:
gcc -O3 -O2 foo.c
GCC will use the last optimization flag passed (in this case O2). However, is this true for all flags? For example, if I execute GCC like so:
gcc -mno-sse -msse bar.c
Will it support SSE since that was the last flag passed, or would this result in undefined behavior? My initial experimentation seems to indicate that it will support SSE, but I'm not sure if this is true for all cases.
Normally later options on the line override ones passed previously, as you mention in your first example. I haven't personally come across any different behaviour for -m or -f flags, but I don't know of a specific reference in the documentation.
Note that some options don't behave this way:
$ gcc example.c -DABC -DABC=12
<command-line>: warning: "ABC" redefined
<command-line>: warning: this is the location of the previous definition
So there would need to be a -UABC in between there to shut that warning up.
As an aside, clang is particularly good at solving this problem - it will produce a warning if it ignores a command line option, which can help you out.
I've recently learned how to program simple character drivers and while playing around with the code I noticed that I get a lot of the following GCC warnings thrown for my C99 code:
warning: ISO C90 forbids mixed declarations and code
I assume this is because the main Linux kernel Makefile is set to compile using a non-C99 standard. I searched around I found this answer here on stackoverflow: How to use make and compile as C99?
So I naturally tried the following in my Makefile:
ccflags-y := -std=gnu99
Unfortunately this didn't silence the GCC warnings. I checked the verbose output of make and verified that GCC is indeed executed with the -std=gnu99 tacked on at the end; so I'm a bit confused.
How do I properly compile a Linux kernel module using the -std=gnu99 option?
EDIT:
I noticed the GCC output shows this option: -Wdeclaration-after-statement. Is this why I am getting the warnings even with the -std=gnu99 option?
It turns out that -std=gnu99 does in fact work; I began seeing errors regarding C99 features after removing the compiler flag. So that meant something else was causing the warnings to print out besides the -std= option.
After parsing through the verbose output via make V=1, I discovered the -Wdeclaration-after-statement option as part of the GCC execution. This was the cause of the ISO C90 mixed declaration warnings I saw.
To disable the ISO C90 warnings, pass this to GCC: -Wno-declaration-after-statement.
For example:
ccflags-y := -std=gnu99 -Wno-declaration-after-statement
You can also specify the flag in your Makefile, if you have one:
FLAGS=-std=gnu99
I'm trying to build GCC for use with an AVR microcontroller and avr-ada, and I've hit a roadblock caused by my regular compiler being too picky about the version I needed for the AVR. I get the following warning, which in turn causes GCC or Make to report an error:
gcc -c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada
-I../../gcc/ada ../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
exp_ch5.adb:177:16: warning: function "Has_Address_Clause" is not referenced
make[2]: *** [ada/exp_ch5.o] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
Is there a way to instruct GCC or Make to not fail on warnings?
Try make -k instead of just make. That will 'continue' rather than stop.
As an alternative to diving into the build system, try setting -Wno-error in CFLAGS, which you should be able to do through the environment (or at configure time, if using the GNU build system).
The trigger here is the -gnatpg (actually, the -gnatg): this is the "GNAT implementation mode (used for compiling GNAT units)". -gnatp means "suppress all checks".
I'm not sure of the full effect of -gnatg, though it certainly causes warnings to be treated as errors -- like -Werror -- at any rate while building the compiler itself; I think I remember seeing non-fatal warnings while building the RTS.
One possibility would be to compile just exp_ch5.adb by hand without -gnatg; the command you list was issued at gcc/, so
$ cd gcc
$ gcc -c -g -O2 -gnatp -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada \
../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
Then back up one level, and 'make' again.
This is a cross-compiler, so you won't (I hope!) need to repeat this for all three stages of a full build.
It seems the -Werror flag is set in the Makefile. Maybe you can look for the CFLAGS options in the Makefile and remove the -Werror flag. The Werror flag will make all warnings into errors.
In general, it is not a good idea to ignore warnings from your compiler. However, if this is a portion of a larger make process there is likely a -Werror flag inserted earlier in the sequence. Start by looking for that.
After looking around, there seems to be a wealth of flags to control warnings while compiling Ada code. For instance, -gnatwF will Suppress warnings on unreferenced formals according to this guide. Possibly the switch you require can be found in the list provided there.
In gcc configure you can add --disable-werror.
Though it's advisable to seek out a proper patch first.
Put "pragma warnings(off, "...")" into the offending parts of your code.
See http://www.adacore.com/2007/11/19/ada-gem-18/.