https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #13) > Yes, the fact that ranger doesn't operate as a usual propagator with a > lattice > makes things very difficult here. Note that my comment referred to code > optimality, not correctness. > > > It really looks like the problem here is DCE (and the gimplifier as you > > point out in comment #2), which is removing a needed statement. Can't this > > be fixed there? > > Sure it can, but the expense is that we'd do constant folding all the way > down and not remove dead code which will result in _tons_ of unnecessary > constant pool entries and loads. > I think I'm missing something, or not understanding what you are saying. Why is the propagation or lack of lattice a problem? Its DCE that is removing that potentially trapping stmt because its no longer used in the IL? THe change would be to not kill off dead statements that may trap? I guess this may leave a bunch of feeding statements that are not dead.. but I fail to see how thats different than not propagating and then not being able to delete those stmts either? > The issue is also that -ftrapping-math is default on so we'd have to > do this by default. Ugh. > > Note that the constant folding routines generally refrain from folding > when that loses exceptions, it's just ranger when producing singleton > ranges and propagating from them that doesn't adhere to that implicit rule. I'm also not sure what this means. I don't think ranger itself propagates singleton constants.. VRP is still using the substitute_and_fold engine, so any folding/propagation is still going through the same mechanisms we always did when a singleton result is produced. We just produce more of them now, especially with floats. I don't think ranger is doing anything different than VRP ever did regarding propagation. Its possible GCCs infrastructure for dealing with float propagation isn't mature enough perhaps?
