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
Related
I wrote a code in C in Ubuntu which checks for balanced brackets in the input given.I compiled it using gcc compiler and I am getting the correct output.This is actually a part of an online course and they are asking me to use the compiler flag
gcc -pipe -O2 -std=c11 filename -lm
I don't think I understand what I am supposed to do so I tried compiling using this flag and my code is not compiling. My question is if my code compiles when I do
gcc filename.c
why isn't it compiling when I do
gcc -pipe -O2 -std=c11 filename -lm
The error message I am getting is :
cc1plus: warning: command line option ‘-std=c11’ is valid for C/ObjC but not for C++
The reason is the file ending. A capital C is interpreted as a C++ file. The solution is to just rename the file like this:
mv filename.C filename.c
My question is if my code compiles when I do gcc filename.C why isn't it compiling when I do gcc -pipe -O2 -std=c11 <filename> -lm
See above. But there are some situations where it would not solve everything. While C11 gives some extensions to previous versions, it's not 100% backwards compatible.
-std=c11 is a correct option
however you need at least gcc 4.7 or higher to have this option
By "<filename>" they mean to substitute in the name of the file you want to compile. Including the literal string "<filename>" will not work.
A function, before being used, needs to be declared either in a included header or otherwise (though not a good practice). The header file describes the functions and variables that may be found in a library or an object file and the compiler can create (as of yet) unreferenced symbols to be resolved later whilst linking.
However, my compiler (gcc based toolchain called esp-open-sdk (xtensa CPU)) continues despite finding no reference to a function in the headers and only in the linking stage does the linker intimate of an `undefined reference to <-function-name->'.
Another strange behaviour is that the compiler says nothing if there is no return statement, and the function is not "void".
My question is: What is causing this behaviour? I think it's unlikely but is it some compiler flag?
My compiler flags are:
CFLAGS = -Os -g -O2 -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH
and the linker flags are:
LDFLAGS = -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static
Probably you use an old version of gcc. Before version 5.x, gcc defaults to a non-standard called "gnu90", which is a non-standard version of the obsolete C90 standard. There is no reason to ever use gnu90 unless you are maintaining some old Linux code. To avoid this, compile with:
-std=c11 -pedantic-errors
-std=c11 meaning you want the compiler to use the current C standard, without involving gnus or other strange animals. -pedantic-errors means that you want it to actually follow the standard and not just pretend to do it.
In order to get the warning for no return from functions, you need to use the option -Wreturn-type, which is included by using -Wall. Always compile with
-Wall -Wextra
Note that "Wall" does not stand for "all warnings", as it leads you to believe. Rather, -Wall means a fistful of warnings and -Wextra means a few warnings more.
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.
for an autotools-based C project, I'd like to get some more warnings from the compiler (e.g. at least -Wall in CFLAGS). What is the prefered way to enable compiler flags without breaking anything? Is there a m4 macro that tests if a given compiler flag is understood by the compiler?
With such a macro I could do
TEST_AND_USE(-Wall -Wextra <other flags>)
Thanks
You can just use AC_TRY_COMPILE:
AC_MSG_CHECKING(whether compiler understands -Wall)
old_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -Wall"
AC_TRY_COMPILE([],[],
AC_MSG_RESULT(yes),
AC_MSG_RESULT(no)
CFLAGS="$old_CFLAGS")
2015 addition: AC_TRY_COMPILE is now deprecated, instead you should use AC_COMPILE_IFELSE:
AC_MSG_CHECKING(whether compiler understands -Wall)
old_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -Wall"
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
AC_MSG_RESULT(yes),
AC_MSG_RESULT(no)
CFLAGS="$old_CFLAGS")
Don't bother changing the configure.ac at all. Just call ./configure with the CFLAGS you care about:
./configure CFLAGS='-Wall -Wextra -O2 -g'
Widely used is the attributes.m4 CC_CHECK_CFLAG_APPEND macro from the xine project. Although, you often find variants (since it's quite simple) written directly in configure.ac
I do this:
# debug compilation
AC_ARG_ENABLE(debug,
AC_HELP_STRING(--enable-debug, [Debug compilation (Default = no)]),
enable_debug=$enableval, enable_debug=no)
if test "$enable_debug" = "yes" ; then
CFLAGS="$CFLAGS -g -O0 -Wall -Wno-uninitialized"
CXXFLAGS="$CXXFLAGS -g -O0 -Wall -Wno-uninitialized"
fi
it is a low-tech solution, but you do not have to accommodate all compilers