when i try to include a .h file which consists of definition for inline functions as
__attribute__( ( always_inline ) ) __STATIC_INLINE uint32_t __SLA (int32_t o1, int32_t o2, int32_t o3)
it is giving the "warning: always_inline function might not be inlinable [-Wattributes]" can you somebody help me i am struggling to fix it.
For functions declared inline(!!!!), this attribute inlines the function independent of any restrictions that otherwise apply to inlining.
So, when you set the attribute without declaring the function inline you will get these warning. Declare the function additionally inline will void these warnings. Behavior gnu gcc/g++ 5.30
# define FORCE_INLINE __attribute__((always_inline)) inline
FORCE_INLINE vec3 operator- (vec3 a, vec3 b) { vec3 t = { a.x-b.x, a.y-b.y, a.z-b.z }; return t; }
finally, after spending two days efforts found the solution as it is below
it is just because of a compiler(arm-none-eabi-gcc) option in Makefile
CFLAGS= -D inline if this flag is set, it throws warning as __attribute__( ( always_inline ) ) __STATIC_INLINE(inline) uint32_t __SLA (int32_t o1, int32_t o2, int32_t o3) when trying to include a .h file which consists of always inline functions
What that warning is saying is that the compiler, is not always happy accepting your function as inline, or it wants it to be declared as inline.
I guess it's that __attribute__ ((always_inline)) implies inline - in which case the parsing of the attribute needs to set DECL_DECLARED_INLINE_P.
The GCC manual specifies
always_inline Generally, functions are not inlined unless optimization is specified. For functions declared inline, this attribute inlines the function even if no optimization level is specified.
Here's the gcc test for the revision
__attribute__ ((always_inline)) does not imply "inline" in gcc. If you use __attribute__ ((always_inline)) without also using "inline" then you will see this gcc warning message, unless it is disabled:
warning: 'always_inline' function might not be inlinable
In the original post I suspect that __STATIC_INLINE(inline) is intended to expand to static inline.
There may be other reasons why the function cannot be inlined, for example if it is recursive.
Related
For instance:
Bool NullFunc(const struct timespec *when, const char *who)
{
return TRUE;
}
In C++ I was able to put a /*...*/ comment around the parameters. But not in C of course, where it gives me the error:
error: parameter name omitted
I usually write a macro like this:
#define UNUSED(x) (void)(x)
You can use this macro for all your unused parameters. (Note that this works on any compiler.)
For example:
void f(int x) {
UNUSED(x);
...
}
In GCC, you can label the parameter with the unused attribute.
This attribute, attached to a variable, means that the variable is
meant to be possibly unused. GCC will not produce a warning for this
variable.
In practice this is accomplished by putting __attribute__ ((unused)) just before the parameter. For example:
void foo(workerid_t workerId) { }
becomes
void foo(__attribute__((unused)) workerid_t workerId) { }
You can use GCC or Clang's unused attribute. However, I use these macros in a header to avoid having GCC specific attributes all over the source, also having __attribute__ everywhere is a bit verbose/ugly.
#ifdef __GNUC__
# define UNUSED(x) UNUSED_ ## x __attribute__((__unused__))
#else
# define UNUSED(x) UNUSED_ ## x
#endif
#ifdef __GNUC__
# define UNUSED_FUNCTION(x) __attribute__((__unused__)) UNUSED_ ## x
#else
# define UNUSED_FUNCTION(x) UNUSED_ ## x
#endif
Then you can do...
void foo(int UNUSED(bar)) { ... }
I prefer this because you get an error if you try use bar in the code anywhere, so you can't leave the attribute in by mistake.
And for functions...
static void UNUSED_FUNCTION(foo)(int bar) { ... }
Note 1):
As far as I know, MSVC doesn't have an equivalent to __attribute__((__unused__)).
Note 2):
The UNUSED macro won't work for arguments which contain parenthesis,
so if you have an argument like float (*coords)[3] you can't do,
float UNUSED((*coords)[3]) or float (*UNUSED(coords))[3]. This is the only downside to the UNUSED macro I found so far, and in these cases I fall back to (void)coords;.
Seeing that this is marked as gcc you can use the command line switch Wno-unused-parameter.
For example:
gcc -Wno-unused-parameter test.c
Of course this effects the whole file (and maybe project depending where you set the switch) but you don't have to change any code.
With GCC with the unused attribute:
int foo (__attribute__((unused)) int bar) {
return 0;
}
A gcc/g++ specific way to suppress the unused parameter warning for a block of source code is to enclose it with the following pragma statements:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
<code with unused parameters here>
#pragma GCC diagnostic pop
Since C++ 17, the [[maybe_unused]] attribute can be used to suppress warnings about unused parameters.
Based on the OP's example code:
Bool NullFunc([[maybe_unused]] const struct timespec *when, [[maybe_unused]] const char *who)
{
return TRUE;
}
I got the same problem. I used a third-part library. When I compile this library, the compiler (gcc/clang) will complain about unused variables.
Like this
test.cpp:29:11: warning: variable 'magic' set but not used [-Wunused-but-set-variable]
short magic[] = {
test.cpp:84:17: warning: unused variable 'before_write' [-Wunused-variable]
int64_t before_write = Thread::currentTimeMillis();
So the solution is pretty clear. Adding -Wno-unused as gcc/clang CFLAG will suppress all "unused" warnings, even thought you have -Wall set.
In this way, you DO NOT NEED to change any code.
Labelling the attribute is ideal way. MACRO leads to sometime confusion.
and by using void(x),we are adding an overhead in processing.
If not using input argument, use
void foo(int __attribute__((unused))key)
{
}
If not using the variable defined inside the function
void foo(int key)
{
int hash = 0;
int bkt __attribute__((unused)) = 0;
api_call(x, hash, bkt);
}
Now later using the hash variable for your logic but doesn’t need bkt. define bkt as unused, otherwise compiler says'bkt set bt not used".
NOTE: This is just to suppress the warning not for optimization.
In MSVC to suppress a particular warning it is enough to specify the it's number to compiler as /wd#. My CMakeLists.txt contains such the block:
If (MSVC)
Set (CMAKE_EXE_LINKER_FLAGS "$ {CMAKE_EXE_LINKER_FLAGS} / NODEFAULTLIB: LIBCMT")
Add_definitions (/W4 /wd4512 /wd4702 /wd4100 /wd4510 /wd4355 /wd4127)
Add_definitions (/D_CRT_SECURE_NO_WARNINGS)
Elseif (CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_GNUC)
Add_definitions (-Wall -W -pedantic)
Else ()
Message ("Unknown compiler")
Endif ()
Now I can not say what exactly /wd4512 /wd4702 /wd4100 /wd4510 /wd4355 /wd4127 mean, because I do not pay any attention to MSVC for three years, but they suppress superpedantic warnings that does not influence the result.
I've seen this style being used:
if (when || who || format || data || len);
For the record, I like Job's answer, but I'm curious about a solution just using the variable name by itself in a "do-nothing" statement:
void foo(int x) {
x; /* unused */
...
}
Sure, this has drawbacks; for instance, without the "unused" note it looks like a mistake rather than an intentional line of code.
The benefit is that no DEFINE is needed and it gets rid of the warning.
The Clang 6.0.1 avxintrin.h has the declaration:
static __inline __m256i __DEFAULT_FN_ATTRS _mm256_set1_epi32(int)
GCC 5.5 has:
extern __inline __m256i __attribute__((__gnu_inline__, _always_inline__, __artificial__)) _mm256_set1_epi32(int)
Why would one be extern and one static? This is showing up for me in an inline function that calls _mm256_set1_epi32. Clang wants it to be declared static:
#include <immintrin.h>
inline void SimdBlockBloomFilter_make_mask() {
_mm256_set1_epi32(1);
}
With -Weverything:
warning: static function '_mm256_set1_epi32' is used in an inline
function with external linkage [-Wstatic-in-inline]
This error does not show up when compiling with Clang++.
In the GCC version, the gnu_inline attribute is close to the behavior of static inline in C99 and later modes.
The C committee ignored the GNU precedent when redefining the meaning of extern inline: With the GNU compiler, extern inline meant that the compiler should never generate a non-inline copy of the function (even if its address is taken). In C99, extern inline means that a definition in a translation unit completes an inline definition in another translation unit.
The GCC version of <immintrin.h> uses the gnu_inline attribute to get the expected behavior in all compiler modes (C89/C90 and C99 in particular).
Doing cc -std=c99 example.c on the following simplified example.c file:
inline void a()
{
}
int main()
{
a();
return 0;
}
gets me:
In function `main':
example.c:(.text+0x7): undefined reference to 'a'
collect2: ld returned 1 exit status
As I understand this has to do with the requirement of C99 standard to demand exactly one more definition for each inline non-static function that is used in cases where the body cannot be inlined? If that is so, I am guessing I could do with static inline instead, but I don't want this to bite me later, so what would be the best course of action here? Obviously, I want to stick to C99 and I want to inline some functions. (Yes, I am aware the compiler usually knows what to inline without being told so, but I have my reasons)
Probably you wouldn't have that error when you compile with -O2 or so.
Inline function definitions should go in header files and an extern inline declaration should go in one compilation unit. Do
inline void a(void){
// empty
}
// in just one .c file
#include "the-file.h"
extern inline void a(void);
BTW, declaring a without void is not a prototype.
There's no function prototype, that's all, so the function signature is inferred, and inferred wrong. Add "void a();" to the top of the file, and you're all set.
// common.h
// This is foo function. It has a body.
__inline void foo() { /* something */ }
// a.cpp
#include "common.h" // for foo function
// Call foo
// b.cpp
#include "common.h" // for foo function
// Call foo
I would like to inline the foo function only when I build for release. I don't want to inline functions for Debug build.
I tried it but linker errors annoyed me.
In this case, foo function's body is defined in common.h header file.
so if I just do
//common.h
#if !defined(_DEBUG)
__inline
#endif
void foo() { /* something */ }
It will be met a link error in DEBUG build. Because two modules try to include common.h.
I have no idea to solve it.
Is it possible?
The "easy" solution would be this:
#if !defined(_DEBUG) || defined(NDEBUG)
#define INLINE inline
#else
#define INLINE static
#endif
static is necessary to silence linking errors and get around the One Definition Rule.
A better solution would be to simply disable inlining project wide for debugging. GCC supports the -wno-inline-functions and -fno-inline-small-functions options to counteract those optimizations, and it also does not enable inlining for -O1 or lower (and probably -Os as well). Most compilers have similar options.
I call the latter a better solution because it should instruct the compiler to ignore the inline hint, eliminating the need for pesky preprocessor directives.
The fundamental thing to realize is that the inline keyword (or Microsoft's __inline extension for C - since MSVC doesn't support C99) is essentially a pass to violate the one definition rule. If you think about it - that's all it really is, since the compiler is under no obligation to actually perform any inlining.
So, when you have an inline function you're allowed to have the function defined in more than one module. In fact, you're obligated to have it defined in any module that actually uses the function.
However, if you don't declare the function as inline, you have to ensure that you have no more than one definition (exactly one if it actually gets used). For non-member functions (all function in C), there are a few ways around this:
declare the function as static to change it's linkage to internal (note that you can have static inline functions to begin with).
in C++ you can place them in an anonymous namespace (which has an effect similar to declaring the static)
you can use preprocessor manipulation to handle this. It's kind of ugly, but it works, and I've seen the technique used successfully in the wild. Whether it's worth the effort is another thing altogether - you'll have to decide that yourself.
Basically, what you need to do is have an implementation of the function in a separate .c file, just like if you were following the tradition of a-single-function-per-module coding standard (actually you can do this just as well putting several inline functions in the .c module - but they should all be inline or not inline as a group to keep things from getting too out of hand). The implementation of the function needs to arrange to be able to be included in a header - so it needs include guards, just like any other header. Then you use the preprocessor to conditionally include the implementation as part of the header when you want inline functions (so the implementation will be available to all modules), but don't include it if you're not inlining (so you follow the one definition rule in that case):
The common.h header:
// common.h
#ifndef COMMON_H
#define COMMON_H
#ifdef RELEASE
#define USE_INLINE
#define INLINE __inline
#else
#define INLINE
#endif
INLINE void foo(void);
#ifdef USE_INLINE
#include "foo.c"
#endif
#endif /* COMMON_H */
The implementation of foo():
// foo.c
#ifndef FOO_C
#define FOO_C
#include <stdio.h>
#include "common.h"
INLINE void foo()
{
printf("foo\n");
}
#endif /* FOO_C */
And an example program:
// main.c
#include<stdio.h>
#include "common.h"
int main()
{
foo();
return 0;
}
Now if you compile for release:
cl /DRELEASE main.c foo.c
foo() will be inline (or __inline as the case may be).
If you compile for non-release:
cl test.c foo.c
you have a non-inline foo().
And both the compiler and linker are happy in either case.
All that said, I kind of like the suggestion to maybe redefine INLINE to be static for debugging purposes.
However, ultimately I'm not sure I see the point to any of this really - modern debuggers are able to step through functions that are inline, and the debugger probably won't inline function calls if you disable optimizations. So you can set breakpoints inside the inline function as well and have it work fine in non-optimized builds.
I'm not sure exactly what you're end-goal in this really is. What's the drawback to leaving the functions as inline in debug/non-optimized builds?
#ifdef RELEASE
#define INLINE __inline
#else
#define INLINE
#endif
Then
// common.h
INLINE void foo() { /* something */ }
// a.cpp
#include "common.h" // for foo function
// Call foo
// b.cpp
#include "common.h" // for foo function
// Call foo
then define RELEASE for the release version. of course you can see from this there are lots of ways to do it.
You can't declare header only functions as non-inline. You could declare them as static (a.k.a. C-style static), but that will generate a copy of the function (including local static variables, if any) in each translation unit. A better solution is to leave it as inline. In debug mode when optimizations are disabled compilers usually don't inline any functions.
In most cases release flags are not defined. Typically debug flags are defined.
_DEBUG is defined by most compilers, so there is no need to define a release flag:
More practical:
#ifndef _DEBUG
__inline void foo() { /* something */ }
#else
//some alternative
#endif
Use compiler conditionals and define a compile time flag.
Example:
#ifdef RELEASE_BUILD_FLAG
//Run inline function
#else
//some alternative
#endif
For instance:
Bool NullFunc(const struct timespec *when, const char *who)
{
return TRUE;
}
In C++ I was able to put a /*...*/ comment around the parameters. But not in C of course, where it gives me the error:
error: parameter name omitted
I usually write a macro like this:
#define UNUSED(x) (void)(x)
You can use this macro for all your unused parameters. (Note that this works on any compiler.)
For example:
void f(int x) {
UNUSED(x);
...
}
In GCC, you can label the parameter with the unused attribute.
This attribute, attached to a variable, means that the variable is
meant to be possibly unused. GCC will not produce a warning for this
variable.
In practice this is accomplished by putting __attribute__ ((unused)) just before the parameter. For example:
void foo(workerid_t workerId) { }
becomes
void foo(__attribute__((unused)) workerid_t workerId) { }
You can use GCC or Clang's unused attribute. However, I use these macros in a header to avoid having GCC specific attributes all over the source, also having __attribute__ everywhere is a bit verbose/ugly.
#ifdef __GNUC__
# define UNUSED(x) UNUSED_ ## x __attribute__((__unused__))
#else
# define UNUSED(x) UNUSED_ ## x
#endif
#ifdef __GNUC__
# define UNUSED_FUNCTION(x) __attribute__((__unused__)) UNUSED_ ## x
#else
# define UNUSED_FUNCTION(x) UNUSED_ ## x
#endif
Then you can do...
void foo(int UNUSED(bar)) { ... }
I prefer this because you get an error if you try use bar in the code anywhere, so you can't leave the attribute in by mistake.
And for functions...
static void UNUSED_FUNCTION(foo)(int bar) { ... }
Note 1):
As far as I know, MSVC doesn't have an equivalent to __attribute__((__unused__)).
Note 2):
The UNUSED macro won't work for arguments which contain parenthesis,
so if you have an argument like float (*coords)[3] you can't do,
float UNUSED((*coords)[3]) or float (*UNUSED(coords))[3]. This is the only downside to the UNUSED macro I found so far, and in these cases I fall back to (void)coords;.
Seeing that this is marked as gcc you can use the command line switch Wno-unused-parameter.
For example:
gcc -Wno-unused-parameter test.c
Of course this effects the whole file (and maybe project depending where you set the switch) but you don't have to change any code.
With GCC with the unused attribute:
int foo (__attribute__((unused)) int bar) {
return 0;
}
A gcc/g++ specific way to suppress the unused parameter warning for a block of source code is to enclose it with the following pragma statements:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
<code with unused parameters here>
#pragma GCC diagnostic pop
Since C++ 17, the [[maybe_unused]] attribute can be used to suppress warnings about unused parameters.
Based on the OP's example code:
Bool NullFunc([[maybe_unused]] const struct timespec *when, [[maybe_unused]] const char *who)
{
return TRUE;
}
I got the same problem. I used a third-part library. When I compile this library, the compiler (gcc/clang) will complain about unused variables.
Like this
test.cpp:29:11: warning: variable 'magic' set but not used [-Wunused-but-set-variable]
short magic[] = {
test.cpp:84:17: warning: unused variable 'before_write' [-Wunused-variable]
int64_t before_write = Thread::currentTimeMillis();
So the solution is pretty clear. Adding -Wno-unused as gcc/clang CFLAG will suppress all "unused" warnings, even thought you have -Wall set.
In this way, you DO NOT NEED to change any code.
Labelling the attribute is ideal way. MACRO leads to sometime confusion.
and by using void(x),we are adding an overhead in processing.
If not using input argument, use
void foo(int __attribute__((unused))key)
{
}
If not using the variable defined inside the function
void foo(int key)
{
int hash = 0;
int bkt __attribute__((unused)) = 0;
api_call(x, hash, bkt);
}
Now later using the hash variable for your logic but doesn’t need bkt. define bkt as unused, otherwise compiler says'bkt set bt not used".
NOTE: This is just to suppress the warning not for optimization.
In MSVC to suppress a particular warning it is enough to specify the it's number to compiler as /wd#. My CMakeLists.txt contains such the block:
If (MSVC)
Set (CMAKE_EXE_LINKER_FLAGS "$ {CMAKE_EXE_LINKER_FLAGS} / NODEFAULTLIB: LIBCMT")
Add_definitions (/W4 /wd4512 /wd4702 /wd4100 /wd4510 /wd4355 /wd4127)
Add_definitions (/D_CRT_SECURE_NO_WARNINGS)
Elseif (CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_GNUC)
Add_definitions (-Wall -W -pedantic)
Else ()
Message ("Unknown compiler")
Endif ()
Now I can not say what exactly /wd4512 /wd4702 /wd4100 /wd4510 /wd4355 /wd4127 mean, because I do not pay any attention to MSVC for three years, but they suppress superpedantic warnings that does not influence the result.
I've seen this style being used:
if (when || who || format || data || len);
For the record, I like Job's answer, but I'm curious about a solution just using the variable name by itself in a "do-nothing" statement:
void foo(int x) {
x; /* unused */
...
}
Sure, this has drawbacks; for instance, without the "unused" note it looks like a mistake rather than an intentional line of code.
The benefit is that no DEFINE is needed and it gets rid of the warning.