1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: enabling LTO by default is vastly inappropriate (was Re: Bug#101538

    From Adam Borowski@21:1/5 to Thorsten Glaser on Tue Jul 19 20:10:01 2022
    On Tue, Jul 19, 2022 at 05:15:32PM +0000, Thorsten Glaser wrote:
    Matthias Klose dixit:
    The goal is to enable this optimization by default in an upcoming
    Debian release in dpkg-buildflags for 64bit architectures. The goal
    is to get this package to build with link time optimizations, or to >explicitly disable link time optimizations for this package build.

    This is daring, especially from the GCC maintainer.

    GCC (both in Debian and upstream) have been ignoring many known
    bugs related to LTO (both in the -fwhole-program --combine and

    I have tried LTO when it came out, on a number of quite large complex codebases. In the 4.* days it was indeed full of bugs. But today,
    the I would say it is good enough for being enabled by default.

    These bugs are subtile miscompilations. In mksh, only one test
    by accident fails due to the GCC LTO bug. It’s definitely *not*

    What was the last version of gcc that you have tested?

    (As for dietlibc, it’s inappropriate there anyway, so it opts out.)

    That's a shame, as it's specifically a library that could use reduced size
    due to the compiler being able to notice and excise unnecessary bits.

    A glance at the failure log shows that first we have an obvious bug that
    has been uncovered now:

    extern int main(int argc,char* argv[],char* envp[]);
    vs
    int main(int argc,char *argv[])

    then some linker games.


    Meow!
    --
    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is
    ⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of
    ⠈⠳⣄⠀⠀⠀⠀ those "based and redpilled", something nasty.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Thu Jul 21 21:00:01 2022
    Adam Borowski dixit:

    These bugs are subtile miscompilations. In mksh, only one test
    by accident fails due to the GCC LTO bug. It’s definitely *not*

    What was the last version of gcc that you have tested?

    8, 9 and then-snapshot, i.e. 10 prereleases. So, pretty recent.

    (As for dietlibc, it’s inappropriate there anyway, so it opts out.)

    That's a shame, as it's specifically a library that could use reduced size >due to the compiler being able to notice and excise unnecessary bits.

    Right, but it’s full of tricks and not ready for this upstream either.

    A glance at the failure log shows that first we have an obvious bug that
    has been uncovered now:

    extern int main(int argc,char* argv[],char* envp[]);
    vs
    int main(int argc,char *argv[])

    Yah. Both are valid, just not at the same time, I suppose.

    then some linker games.

    As I said, full of tricks. This is beyond packager scope.
    I’d rather suggest this for musl, which also supports static
    linking well¹ and is much more standards-compliant (which
    klibc also isn’t so it’s not an ideal target).

    ① though static-PIE seems broken in Debian’s musl even though
    upstream’s webpages suggest it should work…

    bye,
    //mirabilos
    --
    Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
    schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
    Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)