Given a C++ program that uses GNU autotools, what's the easiest way to compile it with -flto (link time optimization)? My understanding is that it is customary on Unix for such optimization flags to be specified by the user or packager, not by the programmer.
According to this post, the -flto flag needs to be passed as a compilation flag and as a linker flag, so:
./configure CXXFLAGS="-flto" LDFLAGS="-flto" ...
or possibly:
./configure CXXFLAGS="-flto" LDFLAGS="-Wc,-flto" ...
might work.
Related
Normally, one can get GCC's optimized assembler output from a source file using the -S flag in GCC and Clang, as in the following example.
gcc -O3 -S -c -o foo.s foo.c
But suppose I compile all of my source files using -O3 -flto to enable link-time whole-program optimizations and want to see the final compiler-generated optimized assembly for a function, and/or see where/how code gets inlined.
The result of compiling is a bunch of .o files which are really IR files disguised as object files, as expected. In linking an executable or shared library, these are then smushed together, optimized as a whole, and then compiled into the target binary.
But what if I want assembly output from this procedure? That is, the assembly source that results after link-time optimizations, during the compilation of IR to assembly, and before the actual assembly and linkage into the final executable.
I tried simply adding a -S flag to the link step, but that didn't really work.
I know disassembling the executable is possible, even interleaving with source, but sometimes it's nicer to look at actual compiler-generated assembly, especially with -fverbose-asm.
For GCC just add -save-temps to linker command:
$ gcc -flto -save-temps ... *.o -o bin/libsortcheck.so
$ ls -1
...
libsortcheck.so.ltrans0.s
For Clang the situation is more complicated. In case you use GNU ld (default or -fuse-ld=ld) or Gold linker (enabled via -fuse-ld=gold), you need to run with -Wl,-plugin-opt=emit-asm:
$ clang tmp.c -flto -Wl,-plugin-opt=emit-asm -o tmp.s
For newer (11+) versions of LLD linker (enabled via -fuse-ld=lld) you can generate asm with -Wl,--lto-emit-asm.
I want to know when i should use ld linker instead off gcc. I just wrote a simply hello world in c++, of course i include iostream library. If i want make a binary file with gcc i just use:
g++ hello hello.cpp
and i've got my binary file.
Later i try to use ld linker. To get object file i use:
g++ -c hello.cpp. Ok that was easy, but the link command was horrible long:
ld -o hello.out hello.o \
-L /usr/lib/gcc/x86_64-linux-gnu/4.8.4/ \
/usr/lib/gcc/x86_64-linux-gnu/4.8.4/crtbegin.o \
/usr/lib/gcc/x86_64-linux-gnu/4.8.4/crtend.o \
/usr/lib/x86_64-linux-gnu/crti.o \
/usr/lib/x86_64-linux-gnu/crtn.o \
/usr/lib/x86_64-linux-gnu/crt1.o \
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -lstdc++ -lc
I know fact that gcc uses the ld.
Using gcc is better in all cases or just in most cases? Please, tell me somethink about cases where ld linker has advantage.
As you mentioned, gcc merely acts as a front-end to ld at link time; it passes all the linker directives (options, default/system libraries, etc..), and makes sure everything fits together nicely by taking care of all these toolchain-specific details for you.
I believe it's best to consider the GNU toolchain as a whole, tightly integrated environment (as anyone with an experience of building toolchains for some exotic embedded platforms with, say, dietlibc integration will probably agree).
Unless you have some very specific platform integration requirements, or have reasons not to use gcc, I can hardly think of any advantage of invoking ld directly for linking. Any extra linker-specific option you may require could easily be specified with the -Wl, prefix on the gcc command line (if not already available as a plain gcc option).
It is mostly a matter of taste: you would use ld directly when the command-lines are simpler than using gcc. That would be when you are just using the linker to manipulate a small number of shared objects, e.g., to create a shared library with few dependencies.
Because you can pass options to ld via the -Wl option, often people will recommend just using gcc to manage the command-line.
I tried compiling MPI programs with mpicc by passing -O1 -O2 -O3 etc optimization flags. I would like to know whether optimization flags really work with mpicc and also wether mpicc supports all the optimization flags of gcc compiler.
mpicc, mpic++, mpif90, mpif77, etc. are all just wrappers around the actual system compiler. Any option that the wrapper does not recognise as its own gets passed to the actual compiler. You can see what is being invoked behind the scenes by calling mpicc with the -showme option:
$ mpicc -showme
gcc ... <lots of options> ...
absolutely. All flags passed to mpicc, mpic++ and the likes are passed to the "original" compiler.
I am building a large project with a makefile that was originally built with icpc, and now I need to get it running with g++.
When it compiles the file that uses openmp, it uses the -c flag, and doesn't use any libraries, so it ends up being serial instead of openmp. All of the examples I am seeing aren't using this -c flag.
Is there some way to compile without linking, but using openmp?
edit:
I've been using the -lgomp flag(and the library is on the library path):
g++ -lgomp -c -w -O4 mainS.cpp
g++: -lgomp: linker input file unused because linking not done
Edit: my boss made several mistakes in the code, the makefile, and the documentation. Sorry to have wasted your time, at least it was less than the 5 hours I spend on it =/
Are you passing the flag to enable OpenMP (IIRC it's something like -fopenmp? If you don't chances are the compiler will ignore the OpenMP-related primitives and just produce serial code.
I don't think that -c (ie, compile only, don't like) has anything to do with your problem.
Perhaps the documentation helps...
Is there a way to force '-m64' not overriding CXXFLAGS/CFLAGS. I want automatic x64 build environment like in Linux/BSD amd64.
Why do I need this?
The problem is complexity of the project I need to be buit as x64 on Solaris. It contains several parts and each may use specific C/C++ compiler flags. So, I can't just run:
CXXFLAGS=-m64 O2 ...
CFLAGS=-m64 -O2 ...
./configure
because there are no common C/C++ flags.
All I need is the way to transparently append '-m64' to every gcc/g++ call.
You can write a wrapper (eg: ~/bin/gcc) that would add the required option(s) and put ~/bin first in your PATH. eg:
#!/bin/ksh
/usr/sfw/bin/gcc -m64 "$#"
CPPFLAGS is used for the c preprocessor. It should be picked up by both gcc and g++.
Reference: http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html