http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to H.J. Lu from comment #10) > Sources have many FP loops contains codes like: > > rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; > > When they are compiled with > > -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver > -fuse-linker-plugin > > LTO input IRs contain statements like > > powmult_241 = dy11_71 * dy11_71; > powmult_240 = dz11_72 * dz11_72; > _699 = powmult_240 + powmult_80; > rsq11_77 = _699 + powmult_241; > > During the final LTO link, lto1 repeatedly removes loop a preheader > in one pass and adds it back in the next pass. Each removal/add > changes the statements to > > powmult_213 = dy11_71 * dy11_71; > _75 = powmult_213 + powmult_80; > powmult_244 = dz11_72 * dz11_72; > rsq11_77 = _75 + powmult_244; > > Each such re-order may change the FP result slightly. They > can accumulate to such a degree that the end result is > outside of tolerance. Huh, adding a pre-header should _never_ do sth like that. Can you produce a small testcase that exhibits these kind of changes with adding/removing a preheader?