lto

When I'm trying to compile my project with 64-bit mingw (x86_64-5.1.0-posix-seh-rt_v4-rev0) I got messages: BFD: my/project/dir/filename.cpp.obj: plugin needed to handle lto object for each source file. Yet when I compile with 32-bit mingw(i686-5.1.0-posix-dwarf-rt_v4-rev0), everething is OK. My flags are: CXX_FLAGS "-fno-exceptions -fno-rtti -std=c++14 -O3 -fstrict-aliasing -flto -fomit-frame-pointer -march=native -ffast-math -funroll-loops" LINKER_FLAGS "-O1 -s" I tried to add -fuse-linker-plugin and -fno-use-linker-plugin, but it didn't help. My OS is 64-bit Windows 10. I use CLion and

I have tried to compile to assembler my source code with next flags: 1. -flto 2. -flto -ffat-lto-objects 3. -flto -fno-fat-lto-objects Third one provides optimized slim LTO code as written in documentation, but I don't see any difference in the output assembly file between first and second, why? OS: linux Compiler: GCC 4.7 The difference between fat and non-fat object files is that fat object files contains both intermediate language as well as the normally compiled code. At linktime, if you invoke compiler without -flto, fat objects will be handled as normal object files (and LTO information

I am attempting to use GCC 4.9.2 to cross compile an application from Linux (x86_64-pc-linux-gnu) for Windows (x86_64-w64-mingw32). When building targets that link against static libraries and also using link-time optimisation I get undefined reference errors from the linker for all symbols the target uses from the library. eg, building bar.a from bar.cpp int bar (void) {return 42;} and linking with foo.cpp extern int bar (void); int main (int, char**) {bar ();} using the command line x86_64-w64-mingw32-g++ -flto -o foo.o -c foo.cpp x86_64-w64-mingw32-g++ -flto -o bar.o -c bar.cpp x86_64-w64

I've written a standard Analysis pass in LLVM, by extending the FunctionPass class. Everything seems to make sense. Now what I'd like to do is write a couple of intermodular passes, that is, passes that allows me to analyze more than one module at a time. The purpose of one such pass is to construct a call graph of the entire application. The purpose of the other such pass is that I have an idea for an optimization involving function calls and their parameters. I know about interprocedural passes in LLVM, via extending the ModulePass class, but that only allows analysis within a single module.

If I want to compile my project with -flto is it enough to have built gcc with --enable-gold or do I also need to build gold and replace ld with it? And do I need any other flags? Ie I'm doing this gcc -flto one.c two.c According to https://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements , Despite the " link time " name, LTO does not need to use any special linker features. The basic mechanism needed is the detection of GIMPLE sections inside object files. This is currently implemented in collect2 . Therefore, LTO will work on any linker already supported by GCC. Furthermore, the GCC

When I try to build static libraries with -flto , I get undefined reference errors: library.cpp : #include <iostream> void foo() { std::cout << "Test!" << std::endl; } main.cpp : void foo(); int main() { foo(); return 0; } Compilation output : $ g++ -flto -c library.cpp $ ar rcs library.a library.o $ g++ -flto main.cpp library.a /tmp/ccZIgxCY.ltrans0.ltrans.o: In function `main': ccZIgxCY.ltrans0.o:(.text+0x5): undefined reference to `foo()' collect2: error: ld returned 1 exit status It works fine if I link with library.o instead of library.a . What am I missing? This is with GCC 4.9.1 and

Which information does GCC collect when I enable -fprofile-generate and which optimization does in fact uses the collected information (when setting the -fprofile-use flag) ? I need citations here. I've searched for a while but didn't found anything documented. Information regarding link-time optimization (LTO) would be a plus! =D -fprofile-generate enables -fprofile-arcs , -fprofile-values and -fvpt . -fprofile-use enables -fbranch-probabilities , -fvpt , -funroll-loops , -fpeel-loops and -ftracer Source: http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Optimize-Options.html#Optimize-Options PS.