https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > (In reply to Jakub Jelinek from comment #0) > > ... but then > > comes dom2 and happily replaces > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return _1; > > with > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return Inf; > > (I think this is still correct) > > Note this is also a pessimization code-generation wise since if we > preserve the multiplication the result is readily available in a > register but as optimized we have another constant pool entry and load. > > So we might want to consider not propagating constants generated by > operations > we cannot eliminate. If the only consumer is a compare-and-branch we > can of course still end up with a seemingly dead stmt, so this would be only > for the missed optimization. [Sorry for the delayed response. I've been on PTO.] For the original testcase, the propagation happens in DOM: <bb 2> [local count: 1073741824]: _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; return _1; range_of_expr gets called on the return's _1 and correctly returns Inf, which allows cprop_operand to do the replacement. If I understand correctly you're suggesting not propagating constants that were generated by an operation we can't eliminate. In this case, it'd be easy to chase the DEF back to the offending _1 definition (from cprop_operand and every other places where we do propagations based on range_of_expr's result), but ranger doesn't keep track of how it got to an answer, so we'd have to chase all operands used to generate _1?? That'd get hairy pretty fast, unless I'm misunderstanding something. 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?