[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-03 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you share with us the exact source code you are testing and the exact options and the exact versions of GCC?
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #2 from PeteVine --- Is there a quick way to verify the installation is not broken re: LTO? I'd like to avoid posting lots of useless info through a stupid user error :) For example, GCC7 was configured/installed this way: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc7/lib/gcc/arm-linux-gnueabihf/7.0.0/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../configure -v --enable-languages=c,c++,fortran --prefix=/usr/gcc7 --program-suffix=-7 --enable-shared --enable-linker-build-id --libexecdir=/usr/gcc7/lib --without-included-gettext --enable-threads=posix --libdir=/usr/gcc7/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --with-arch-directory=arm --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3 --with-float=hard --with-mode=arm --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --disable-bootstrap Thread model: posix gcc version 7.0.0 20160916 (experimental) (GCC) Every time I switch to a different gcc version I run a script that changes the following symlinks: gcc, g++, gfortran, ar, nm, ranlib, gcov, gcov-tool to their corresponding versioned instances. Never had any problems so far, apart from having to set LD_LIBRARY_PATH for running C++ binaries compiled against newer libstdc++.
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #3 from Richard Biener --- If you force (not sure what's the default on your target) -fno-fat-lto-objects then you'll notice if LTO is used at link time.
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #4 from PeteVine --- Just tried your suggestion and during the final link, /tmp is full of ltrans objects so LTO seems to be working fine (GCC5 + -fno-fat-lto-objects) but the stripped size ended up even larger (2.5M). Anyway, here's what works for gcc 4.9.4 (sdl, sdl-ttf, sdl-mixer required): $ export CFLAGS='-mcpu=cortex-a5 -Ofast -marm -fomit-frame-pointer -mfpu=neon -ftree-vectorize -flto' CXXFLAGS='-mcpu=cortex-a5 -Ofast -marm -fomit-frame-pointer -mfpu=neon -ftree-vectorize -flto' git clone -b master git://git.code.sf.net/p/ufoai/code ufoai cd ufoai && make -j4 && strip -s ufo Starting with GCC5, even running: LDFLAGS="$CFLAGS" ./configure ..., etc. makes no difference, which makes me wonder if the LTO part of the GCC5 changelog could be relevant here?
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #5 from PeteVine --- Missed the configure step, just before make: $ ./configure --enable-release --disable-sdl2 --enable-only-ufo
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #6 from PeteVine --- Aha! 4.9.4 and additional LDFLAGS=$CFLAGS reproduces the larger size. (-fno-fat-lto-objects on its own still works as expected) Probably thee clue to solving this mystery :)
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #7 from PeteVine --- The bug doesn't occur on an aarch64 system (built with gcc5): $ du ufo-arm64-gcc* 3312ufo-arm64-gcc5 3072ufo-arm64-gcc5-lto 3256ufo-arm64-gcc6 3056ufo-arm64-gcc6-lto 3288ufo-arm64-gcc7 3040ufo-arm64-gcc7-lto This could mean the issue revolves around C++ gcc4 ABI and libraries built with different libstdc++/gcc versions. Does that sound plausible? (everything works perfectly fine at runtime and there must be a reason the problem starts occurring at gcc5 boundary) The previous comment might be completely tangential to this issue.
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 --- Comment #8 from PeteVine --- Nah, the whole issue's just some sort of build-system artifact, namely, switching to cmake: $ du ufo*cmake* 2076ufo-gcc4.9-lto-cmake 2140ufo-gcc4.9-nonlto-cmake 2064ufo-gcc7-lto-cmake 2124ufo-gcc7-nonlto-cmake Note how the binaries got smaller but 4.9 was not able to match the previously smallest size. Due to the different build system could be apples and oranges, though. (-O2 seems to be enforced here, just noticed)
[Bug lto/77821] C++ binary size increase or LTO not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Biener --- With GCC prior to GCC 5 you need to make sure that -On appears on the GCC linker command line, otherwise -O0 is used IIRC.
