[Bug bootstrap/60160] New: Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[Bug bootstrap/60160] New: Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

            Bug ID: 60160
           Summary: Building with -flto in CFLAGS_FOR_TARGET /
                    CXXFLAGS_FOR_TARGET
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: d.g.gorbachev at gmail dot com

Created attachment 32115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32115&action=edit
Tentative patch

Someone might want to build everything with LTO. Currently, I see two problems.

1. crtstuff.c: perhaps it'd be better to compile it with -fno-lto.
2. attribute used for _Unwind_* functions.

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Note the related: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01480.html (PR
43538) and PR 59893.

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
libstdc++ also causes problems:

/var/tmp/gcc_build_dir_/./prev-gcc/xg++ -B/var/tmp/gcc_build_dir_/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/l
ibstdc++-v3/src/.libs
-B/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/
x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++
-L/var/tmp/gcc_build_dir_/prev-x86_64-pc-lin
ux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -march=native -O3 -pipe -flto=jobserver -frandom-seed=1 -fprof
ile-generate -fno-lto -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedan
tic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterati
ons=3  -o build/genconstants \
    build/genconstants.o build/read-md.o build/errors.o
.././libiberty/libiberty.a

/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
error: undefined reference to 'std::istream::ignore(long)'
/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
error: undefined reference to 'std::basic_istream<wchar_t,
std::char_traits<wchar_t> >::
ignore(long)'

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
ISTR that building with CFLAGS_FOR_TARGET="-g -O2 -flto -ffat-lto-objects",
same for CXXFLAGS_FOR_TARGET, and --disable-bootstrap used to complete, but now
it fails during the link of .libs/libstdc++.so.6.0.21:

lto1: fatal error: /tmp/ccRgW0QI.ltrans5.o: section
_ZTVSd.localalias.316.lto_priv.752 is missing
compilation terminated.
lto-wrapper: fatal error: /tmp/gcc-lto/build/./gcc/xgcc returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

I don't remember ever seeing that "section ... is missing" error before.


Exact line I used:
/data/repos/gcc/trunk/configure --prefix=/tmp/gcc-lto/inst
--enable-languages=c,c++ --with-system-zlib --disable-nls
--enable-libstdcxx-time=yes --disable-bootstrap --disable-libgomp
--disable-libitm --disable-libquadmath --disable-libatomic --disable-libssp
--disable-multilib --disable-libsanitizer --disable-libvtv --disable-libcilkrts

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[d.g.gorbachev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

Dmitry Gorbachev <d.g.gorbachev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32115|0                           |1
        is obsolete|                            |

--- Comment #4 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> ---
Created attachment 33385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33385&action=edit
Updated patch

I have no problems with static libstdc++ (--disable-shared). But there were
some issues with libgcov and profiledbootstrap. Perhaps it should be compiled
without LTO.

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

R. Diez <rdiezmail-gcc at yahoo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rdiezmail-gcc at yahoo dot de

--- Comment #6 from R. Diez <rdiezmail-gcc at yahoo dot de> ---
I am experimenting with a GCC 11.2 cross-compiler for bare-metal embedded
software.

There is no operating system, so no shared libraries or anything fancy. But
there is a static libc (Newlib or Picolibc).

I wanted to build everything with LTO, including libc, libstdc++ and libgcc.
This is the makefile I am using:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile

Search for "-ffat-lto-objects" in that makefile.

As soon as I enable the LTO flags, I get linker errors. They are documented in
the makefile next to the LTO options, and look similar to those reported in
this bug.

I tried -fno-builtin with varying degrees of success. I also tried building
only the application and libc with LTO, but not libstdc++ etc., to no avail.

LTO only works for the user application. As soon as libc or the other GCC
libraries are compiled with LTO, it fails.

Is it unfortunate, because I believe that a full LTO build for a bare-metal
environment would be rather beneficial.

The patch and information referenced in this bug report look dated. Is there a
way to make LTO work now, at least for my configuration?

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to R. Diez from comment #6)
> I am experimenting with a GCC 11.2 cross-compiler for bare-metal embedded
> software.
> 
> There is no operating system, so no shared libraries or anything fancy. But
> there is a static libc (Newlib or Picolibc).
> 
> I wanted to build everything with LTO, including libc, libstdc++ and libgcc.
> This is the makefile I am using:
> 
> https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile
> 
> Search for "-ffat-lto-objects" in that makefile.
> 
> As soon as I enable the LTO flags, I get linker errors. They are documented
> in the makefile next to the LTO options, and look similar to those reported
> in this bug.
> 
> I tried -fno-builtin with varying degrees of success. I also tried building
> only the application and libc with LTO, but not libstdc++ etc., to no avail.
> 
> LTO only works for the user application. As soon as libc or the other GCC
> libraries are compiled with LTO, it fails.
> 
> Is it unfortunate, because I believe that a full LTO build for a bare-metal
> environment would be rather beneficial.

I agree.

> The patch and information referenced in this bug report look dated. Is there
> a way to make LTO work now, at least for my configuration?

Problems can exist in all parts of the toolchain here, in particular the
linker needs to cope with GCC replacing say a reference to printf with
puts (which it will happily do in some cases when not using -fno-builtin).
That might be one source of unresolved symbols.  Generally GCC doesn't
like it very much seeing definitions of functions it also recognizes
as builtins.  It might be needed to teach GCC to do less agressive
dead function removal during WPA or not fold printf to puts late if it
removed a definition of puts.

Other than that I would suggest to enable emitting LTO bytecode for the
static target libraries on a per library base with new configury, say
--enable-fatlto-static-target-libraries or so and do opt-in for those
where it works.

That said - yes, it would be nice, but expect to run into problems.  When
it works, great, when it doesn't - try to analyze the issue and maybe file
a specifc bugreport with a testcase?

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[a.heider at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

Andre Heider <a.heider at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a.heider at gmail dot com

--- Comment #8 from Andre Heider <a.heider at gmail dot com> ---
I tried this too, and so far I ran into this build failure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630

With --enable-symvers=no as a workaround the build succeeds with a shared
libstdc++.

If I build the target's toolchain libraries with LTO (using
{C,CXX,LD}FLAGS_FOR_TARGET), some userland apps fail to link with mold:
mold: error: undefined symbol: __EH_FRAME_BEGIN__.lto_priv.0

Where as bfd links without errors.

As per this bug's description "1. crtstuff.c: perhaps it'd be better to compile
it with -fno-lto." I tried this patch:
diff -ur a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in        2022-08-19 10:09:54.664689148 +0200
+++ b/libgcc/Makefile.in        2023-02-01 21:56:50.561528520 +0100
@@ -301,7 +301,7 @@
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
   $(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
   -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
-  -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
+  -fbuilding-libgcc -fno-stack-protector -fno-lto
$(FORCE_EXPLICIT_EH_REGISTRY) \
   $(INHIBIT_LIBC_CFLAGS) $(USE_TM_CLONE_REGISTRY)


And then the mold linker can build the userland apps in question too.

I only saw this later, but that's one hunk of the patch in comment #4. Is that
patch correct and worth commiting?

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[a.heider at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160

--- Comment #9 from Andre Heider <a.heider at gmail dot com> ---
See also https://github.com/rui314/mold/issues/977
mold v1.10.1 can't handle crt files which are built with LTO enabled.

But it sounds more like LTO on crt as-is produces the wrong thing?
__EH_FRAME_BEGIN__.lto_priv.0 resides in .eh_frame then.