I have just received Bug#1015348 reporting that adns doesn't work with LTO (link-time optimisation).
How does LTO work with ABI compatibility, which we rely on very heavily ? Eg, my reading of the spec is as follows: if I add members to an enum in a new library version, making a combined program containing translation units with the old enum, and ones with the new enum, is UB.[1] But that is precisely what we do when we run new binaries against old libraries. I think src:adns only does things which are justified by traditional ABI compatibility assumptions (albeit, that in some parts of the build it makes these assumptions when linking statically, as well as when linking dynamically). So what, precisely and formally, are the rules ? I feel entitled to demand a fully precise and formal specification of the rules, because it is precisely fully precise and formal and expansive readings of C's literally-incomprehensible[2] specifications which are being used to justify miscompilations (so-called "optimisations"). Frannkly, I think enabling LTO by default is a mistake. The performance benefits are not likely to be worth the bugs silently introduced across our codebase. If there are particular programs that would benefit from it, by all means enable it in those cases. Ian. [1] Assuming that the enum type is used in a relevant way. [2] If anyone doubts that the C specification is literally incomprehensible, observe, for example, the existence of research papers with titles like "Towards a formal semantics for C", or indeed the absolutely hilarious discovery that the specification forgot to define the meaning of assigments when the assignment target was written in parentheses, and that no-one noticed this for decades. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
