I made a simple quick sort algorithm using C language, named test.c
I'm trying to maximize the optimization, so I use -O3 options like belows.
gcc -S -O3 -o test.s test.c
gcc -S -O3 -o test1.s test.s
gcc -S -O3 -o test2.s test1.s
gcc -S -O3 -o test3.s test2.s
.
.
.
But strange thing happens. The more times I did above procedure, the more number of line assembly get.
I don't know why this happens, because I think that I have to get more optimized assembly file that has smaller number of line as I did above procedure.
If this is not right way, using -O3 only one time is the way of the best optimization?
Thanks
Most of the gcc optimizations operate on the representation of C source code in an intermediate language. I'm not aware of any optimization specifically operating at the assembler instruction level other than peephole. But that would also be included in -O3.
So yes, -O3 is supposed to be used only once, when turning C source into object files.
Related
When I run:
/opt/local/bin/arm-elf-gcc-4.7 test.c -o test
gcc decides to use as -o test.o test.s instead of the cross compiler's assembler. How do I specify the correct assembler to use?
Use -B PREFIX to set the correct assembler.
In a particular project, I saw the following compiler options used all at once:
gcc foo.c -o foo.o -Icomponent1/subcomponent1 -Icomponent2/subcomponent1 -Wall -fPIC -s
Are the -fPIC and -s used together contradictory here? If not, why?
-s and -fPIC are two flags used for different purposes. They are not contradictory.
From the gcc manual
-s
Remove all symbol table and relocation information from the executable.
-fPIC
If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC.
I use the following LLVM tools to convert a cpp project which is written in multiple files into "ONE" single assembly file.
clang *.cpp -S -emit-llvm
llvm-link *.s -S -o all.s
llc all.s -march=mips
Is there any way of doing this in GCC? In particular, is there any way of linking GCC generated assembly files into one assembly file? i.e., what is the equivalent of LLVM-LINK?
Perhaps LTO (Link Time Optimization) is what you want.
Then, compile each compilation unit with gcc -flto e.g.
gcc -flto -O -Wall -c src1.c
g++ -flto -O -Wall -c src2.cc
and use also -flto (and the same optimizations) to link them:
g++ -flto -O src1.o src2.o -lsomething
LTO works in GCC by putting, in each generated assembly file and object file, some representation of the internal GCC representations (like Gimple). See its documentation
You might want to use MELT to customize GCC (or simply use its probe to understand the Gimple, or try just gcc -fdump-tree-all).
I use a custom build tool to compile go projects and I need a way to use cgo in my project.
The problem is that the cgo documentation only tells you how to use it with make.
What I really need to know is which generated files to process with which tools and in what order it needs to be done. I tried to read make.pkg in the go source dir but my best effort fails.
My test dll is very simple, a single function that returns 1 every time it is called and the go code to use this function is similarly simple.
The output from the console produced by a successful run of make on a cgo project would be very helpful.
Output of running make on 32-bit Linux in directory misc/cgo/life:
# gomake _obj/life.a
CGOPKGPATH= cgo -- life.go
touch _obj/_cgo_run
8g -o _go_.8 _obj/life.cgo1.go _obj/_cgo_gotypes.go
8c -FVw -I ${GOROOT}/pkg/linux_386 -I . -o "_cgo_defun.8" _obj/_cgo_defun.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_main.o -c _obj/_cgo_main.c
gcc -m32 -g -fPIC -O2 -o c-life.o -c c-life.c
gcc -m32 -I . -g -fPIC -O2 -o life.cgo2.o -c _obj/life.cgo2.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_export.o -c _obj/_cgo_export.c
gcc -m32 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o c-life.o life.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c
8c -FVw -I . -o "_cgo_import.8" _obj/_cgo_import.c
rm -f _obj/life.a
gopack grc _obj/life.a _go_.8 _cgo_defun.8 _cgo_import.8 c-life.o life.cgo2.o _cgo_export.o
The line cgo -- life.go creates the following files:
_obj/_cgo_.o
_obj/life.cgo1.go
_obj/life.cgo2.c
_obj/_cgo_gotypes.go
_obj/_cgo_defun.c
_obj/_cgo_main.c
_obj/_cgo_flags
_obj/_cgo_export.c
_cgo_export.h
"I use a custom build tool to compile go projects and I need a way to use cgo in my project."
... and this approach leads to problems. Using the standard way with a Makefile is simple, easy, proven, documented, etc.
I realize I'm not (directly) answering your question. Instead my "answer" is: I strongly suggest to use the standard way. Don't create problems for your self by choosing other, not directly supported options.
That said, I think there is a way to avoid the Makefiles, I just never been there, sorry. I'm usually lazy/short of time, so I use the simplest/fastest way to get things done. You might want to try the same ;-)
I compiled with gcc
gcc -l. 'net-snmp-config --cflags'
-fPlC -shared -c -o matsu_object.o tsu_object.c
but this error occurred
gcc: -lcrypto: Because a link was
not completed, the input file of the
linker was not used
What's wrong?
Did you mistype the question? There's no way for that to output the message you write, and I would expect that the proper command is something more like
gcc -L. `net-snmp-config --cflags` -fPIC -shared -c -o matsu_object.o tsu_object.c
Notice the -L uppercase, backticks instead of single quotes, and upper-case I in PIC.
Also, you don't say what you're trying to do, but net-snmp-config should also take at least one of --libs or --agent-libs as well.
Ah, I didn't read closely enough...
-c means "compile", that is: generate from tsu_object.c, a compiled matsu_object.o.
Without -c, the compiler actually links, that is: generate from *.o, a.out or other specified file.
-shared (and linker flags like -l and -L) are only meaningful when linking. They're meaningless when compiling, as you are doing here because of -c.
Please correct the command-line in the question to accurately reflect what you're running, and give some more explanation as to what you're trying to do.
I think you are using ticks ' instead of back ticks `. Does --cflags really give linker options? I think you are at the link step here. Also what is the effect of -c at a link. I thought -c was compile only and not attempt to link.
You used single quotes instead of backquotes.
Instead of this:
gcc -l. 'net-snmp-config --cflags' -fPlC -shared -c -o matsu_object.o tsu_object.c
You should type:
gcc -l. `net-snmp-config --cflags`-fPlC -shared -c -o matsu_object.o tsu_object.c
net-snmp-config is a program. When you run it with --cflags, it evaluates to the correct cflags that you should be using to compile your program.
But you know what? You should be using autoconf. Even for something this small, it usually makes sense to do the work. Most people I know need to compile on more than one platform...