On Tue, 4 Oct 2011, Andi Kleen wrote: > > Well, I'm not sure we should jump through too much hoops to make > > -flto work with -fno-toplevel-reorder. Simply because I think nothing > > defines any "toplevel order" for multiple object files. So, I think > > In practice it seems to work because real programs rely on it. > > I can just say with this patch and Honza's my program works > (with -flto-partition=none), without it it doesn't. > > Also as Honza pointed out it has other benefits, like making > compiles more reproducible. For example if you have a memory corruption > somewhere the random order currently will randomly move it from > run to run and make it harder to debug. > > > both ld and gcc/collect2 need to first document they will never > > break toplevel order (what about ld with -ffunction-sections and > > -gc-sections? Or -relax?) > > -ffunction-sections and -gc-sections do not reorder as far as I know. > Not sure about -relax. > > But the programs that rely on order should "don't do it when it hurts" > so not set too magic options. I'm sure there are other creative ways to break > order too, but it doesn't seem to be too hard in practice to avoid > them.
Sure, the question is if "-flto" counts as magic and thus "don't do it when it hurts" ;)) I suppose with -flto-partition=none (or 1to1) it would be reasonable to make -fno-toplevel-reorder work (and thus maybe -fno-toplevel-reorder should simply force 1to1 partitioning). Richard.
