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?
Related
-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.
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.
This question already has answers here:
Recommended GCC warning options for C [closed]
(15 answers)
Closed 8 years ago.
What GCC options should be set to have GCC as strict as possible? (and I do mean as strict as possible) I'm writing in C89 and want my code to be ANSI/ISO compliant.
I'd recommend using:
-Wall -Wextra -std=c89 -pedantic -Wmissing-prototypes -Wstrict-prototypes \
-Wold-style-definition
You should compile with -O as well as -g as some warnings are only available when the optimizer is used (actually, I usually use -O3 for spotting the problems). You might prefer -std=gnu89 as that disables fewer extensions in the libraries. OTOH, if you're coding to strict ANSI C89, maybe you want them disabled. The -ansi option is equivalent to -std=c89 but not quite as explicit or flexible.
The missing prototypes warns you about functions which are used (or external functions defined) without a prototype in scope. The strict prototypes means you can't use 'empty parentheses' for function declarations or definitions (or function pointers); you either need (void) or the correct argument list. The old style definition spots K&R style function definitions, such as:
int old_style(a, b) int a; double b; { ... }
If you're lucky, you won't need to worry about that. I'm not so lucky at work, and I can't use strict prototypes, much to my chagrin, because there are too many sloppy function pointers around.
See also: What is the best command-line tool to clean up code
This set of options is pretty good:
-Wall -Wextra -ansi -pedantic
You'll have to read the documentation to see if there are any extra warnings getting left out by that combination.
You should be warned that strict C89 doesn't include support for // style comments, and there are some pretty serious restrictions on the number of significant characters in the names of objects with external linkage.
I recently stumbled across the following behaviour of gcc 3.2.2 writing a c program:
In an if statement I forgot the braces of a function and wrote:
if(myFunc)... instead of if(myFunc())...
This did not generate an error neither a warning although I have pretty much every warning turned on.
It simply evaluated to true.
Why is this writing legal code in the first place ?
Because the function exists/has an address ?
Does anyone know how one could avoid such mistakes or if there is a warning option I overlooked ? Is this issue better solved in later gcc versions ?
Here the exact compiler call for completeness:
msp430-gcc -g -Os -mmcu=msp430x1611 -Wall -W -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wredundant-decls -Wnested-externs -Wimplicit-function-declaration -Werror
(Since I'm forced to use gcc 3.2.3 there is no -Wextra)
if (myFunc) is equivalent to if (&myFunc), so you're testing the address of a function, which of course will always be non-zero, i.e. true.
With gcc 4.2.1 and -Wall I get the following warning:
myfunc.c:11: warning: the address of ‘myFunc’ will always evaluate as ‘true’
myFunc is simply the memory address of the function, and is non-zero.
Your if-statement is pretty much the same as writing:
if (0x08451234) { ... }
And as a non-zero value, it is true.
No warning seems appropriate, as it is valid and even somewhat common to test function-pointers to see if they are NULL or not.
myFunc, since its the name of a function will always evaluate to true because its a pointer. More specifically it has to be a non-null pointer because you will be needing to dereference it. A null pointer would evaluate to false.
In short, there does not seem to be a way for the compiler to tell you that you've made a mistake.
What you need to do is to have some unit tests that separately invoke the true and false responses so that you can tell that you've actually called the function.
Pointers to functions are sometimes useful - as callbacks eg in sort routines or data capture. Or for doing optimized calculated-goto type routines, since C doesn't have templates.
But 99% of the time it's an error, newer compilers will warn you
This is to support an old linker hack; many compilers/linkers (including gcc and GNU binutils) allow you to define a weak symbol for a function which evaluates to 0 unless another object file/shared library that got linked overrides the value of the symbol. glibc makes use of this trick for some version-compatibility hacks.