On Mon, 25 Aug 2025, G. Branden Robinson via Gcc-help wrote: > [please keep the groff@gnu list CCed; I am not subscribed to gcc-help] > > Hi folks, > > A couple of years ago a groff user and developers ran into a subtle > problem involving object initialization behavior that seemed to change > as one added the `-flto=auto` option, or not. > > https://savannah.gnu.org/bugs/?64421 > > I cannot claim to be a C++ or LTO wizard; I did my best to explain the > problem in a Savannah ticket, ChangeLog file, and commit message, but I > do not feel solid ground beneath me. > > If anyone with relevant expertise is interested, I'd like to request a > review of said ticket and solicit: > > 1. suggestions for a corrected/improved explanation of the fault; and > 2. a ruling in or out of a toolchain defect I should have filed a bug > about 2 years ago. > > My personal wager is that there is a sentence somewhere in ISO/IEC 14882 > that would warn me that groff's code doing what it did from 2002-2023 > was undefined behavior. But I'd rather know than guess. Most likely you are hitting Static Initialization Order Fiasco: https://en.cppreference.com/w/cpp/language/siof.html class color actually has a constructor which will be used for constructing the 'default_color' global object: color(symbol s = default_symbol) : scheme(DEFAULT), nm(s) {} This will copy the uninitialized contents of default_symbol, if its constructor has not completed by that time. Since libgroff is a static library, the order in which constructors run without LTO depends on the order in which linker extracts the object files from libgroff.a static archive when linking. If the dependencies are such that symbol.o is consistently pulled in prior to color.o, the constructor for default_symbol would always run first. Alexander
