top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Can't use -flto with -std=c99 in C program

0 votes
224 views

My application builds fine with -flto, but only if I do not also specify -std=c99.

If someone can help me, that would be wonderful. I have created a very simple test, below, to demonstrate the problem.

main.c:

#include "foo.h"
void main(int argc, char** argv) {
 int input = atoi(argv[1]);
 printf("%dn", foo(input));
}

foo.h:

inline int foo(int x);

foo.c:

#include "foo.h"
inline int foo(int x) {
 while (x < 900) {
 x += x;
 }
 return x;
}

Makefile:

CFLAGS += -flto -std=c99
LDFLAGS += -flto -std=c99

main : main.o foo.o
main.o : main.c foo.h
foo.o : foo.c foo.h

.PHONY : clean

clean :
 $(RM) main main.o foo.o

Results of running make:

cc -flto -std=c99 -c -o main.o main.c

In file included from main.c:3:0:

foo.h:1:12: warning: inline function  foo  declared but never defined [enabled by default]
 inline int foo(int x);
 ^
foo.h:1:12: warning: inline function  foo  declared but never defined [enabled by default]
cc -flto -std=c99 -c -o foo.o foo.c
cc -flto -std=c99 main.o foo.o -o main
/tmp/ccTDIBGZ.ltrans0.ltrans.o:ccTDIBGZ.ltrans0.o:function main: error: undefined reference to 'foo'
collect2: error: ld returned 1 exit status
make: *** [main] Error 1

Without the -std=c99 flags, make runs successfully and without warnings.

posted Jul 1, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

I don't think your program is valid C99 code (even ignoring the fact your main() has the wrong return type).

If a C99 function is declared inline (and not extern) then it is an inline definition, and will not be used for calls to that function from other translation units, so you need to declare it as extern or define it in every translation unit that calls it.

GNU C90 inline functions have different semantics to C99 inline functions:

"When an inline function is not static, then the compiler must assume that there may be calls from other source files; since a global symbol can be defined only once in any program, the function must not be defined in the other source files, so the calls therein cannot be integrated. Therefore, a non-static inline function is always compiled on its own in the usual fashion. "

answer Jul 1, 2013 by anonymous
Similar Questions
+2 votes

There are many builtin versions of various c99 functions. I find it difficult, however, to use them instead of the glibc equivalent, even when calling __builtin_xx directly. Specifically in the case of fminf, under what conditions will gcc give me nice one-line branch-free assembly vs a call out to the library?

+2 votes

I'm curious as to why libstdc++ is using a RB-tree to implement std::set (details here
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/set and here https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/stl_tree.h ),
when there are faster alternatives?

I'm mainly curious, because from all the people I've asked there hasn't been a single answer in favor of RB-trees, other than "they're already popular" or "easy to implement".

If you'd like more details on that, here's a link to my question on stackexchange http://cs.stackexchange.com/questions/41969/why-are-red-black-trees-so-popular,
where nobody has yet answered as well.

Using a variant of B-tree (or (a,b)-tree) should be faster, and everyone seems to suggest so, which makes me wonder what is the reason for picking RB-trees? This is not a question about their theoretical speed, but about real world behavior on real hardware with respect to CPU caches, etc.

+1 vote

Please help me with c program which takes less memory and time to sort a unsorted array of 1000 chars, its order should not be more then O(N) and memory should be most least as possible. Use bit fields and share the program?

...