And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?
Hello,
We just had SuSE embracing LTO
(https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
I am not sure about the progress on issues summarised in
http://blog.regehr.org/archives/1180 that Ian pointed to. But since I
last asked in 2016 we have more pedantic compiler settings and more CI -
and LTO, as much as compilers have improved on that, does not need to be
applied everywhere. Any change in opinion?
Steffen
On 30.03.16 17:22, Ian Jackson wrote:
> Steffen Möller writes ("-flto to become more of a routine - any change
in opinion since 2011?"):
>> I admit to be a fan of link time optimisation and would like to see this
>> challenge promoted towards more of a routine challenge to establish for
>> our packages. I found this informative thread
>>
>> https://lists.debian.org/debian-devel/2011/06/msg00181.html
>
> I have a concern not yet addressed in this thread.
>
> Recently we have seen spectacular advances in compiler optimisation.
> Spectacular in that large swathes of existing previously-working code
> have been discovered, by diligent compilers, to be contrary to the
> published C standard, and `optimised' into non-working machine code.
>
> In fact, it turns out that there is practically no existing C code
> which is correct according to said standards (including C compilers
> themselves). (A full discussion of how this situation came to be is
> probably out of scope for debian-devel, and also might involve me
> becoming quite rude. So I will avoid that.)
>
> I worry that LTO will exacerbate this problem, by extending the
> categories of technical non-compliance (with rules which are very
> difficult to fully comply with) which are detected by compilers and
> transformed into actual non-working code.
>
> IMO Debian should not arrange for users to be using LTO-affected
> executables (in general[1]) until there have been major advances in
> the manageability of the C dialect we are using.
>
> To give an idea of what I think would be necessary, here is an
> excellent posting from Pascal Cuoq, Matthew Flatt, and John Regehr:
> http://blog.regehr.org/archives/1180
> (I don't necessarily agree with this in every detail, but it gives a
> very good idea of the breadth and depth of the changes I think are
> needed.)
>
> In general I highly reccommend Regehr's blog for this kind of topic.
>
> Thanks,
> Ian.
>
> [1] Of course if there are specific programs that are somehow known to
> be in compliance with the rules being newly enforced in LTO, then it
> might be reasonable for those specific packages Debian build systems
> to enable LTO.
>
> However it seems like it will be very rarely in practice possible to
> establish that a program is correct enough to safely enable LTO.
Reply to: