https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Richard Biener from comment #12) > (In reply to Tom de Vries from comment #11) > > Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" ( > > https://sourceware.org/bugzilla/show_bug.cgi?id=25684 ). > > > > Ideally there would be a way to enable the lto infrastructure without > > actually optimizing, such that when running the gdb testsuite with and > > without flto and comparing results, any regression would indicate something > > that needs fixing. > > > > In the current situation, each individual regression needs investigation > > whether something needs fixing or whether the failure is just an > > optimization artifact. And due to the fact there are optimizations, there > > are thousands of such regressions. > > I suppose we're talking about -O0 -flto here. Right, and ideally -flto plain, with -O0 implicit. > What kind of transforms > are undesirable? I think at -O0 you'll get > > - more aggressive unused variable/function removal > - promotion of variables from global to local > Right, is there a way to switch these off? > some of the transforms are unavoidable due to partitioning(?) but we could > default to 1:1 partitioning at -O0 ... At this point I'm not interested in defaults yet. I can achieve 1:1 partition by testing target board unix/-flto/-flto-partition=1to1. For now I'm interested in a combination of flags that exercises the specific type of debug info generation as is done for lto, without actually doing any optimizations. F.i., an open question for me is the following: I'm now using -flto-partition=none for testing, but maybe 1to1 should yield better results?
