https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574
--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #4) > Yeah, but folding would happily create undefined behavior from, say, > > if (x != INT_MIN) > x = x * -1; > > as folding folds INT_MIN * -1 to INT_MIN (ok, maybe with TREE_OVERFLOW > set, but I'm not sure we want to rely on that). The C++ front-end already relies on constant folding detecting undefined behavior, so at least this case seems fine. But there may indeed be symbolic cases where we would simplify the operation assuming that some undefined behavior doesn't occur, while that is precisely what the condition was protecting against... (though I have a hard time coming up with an example that works with a single stmt) So fold may not be quite the right interface. Maybe we should mark in some way the transformations that assume a restricted range, so we can generate a limited version of fold where the reverse transformation is safe. Not something for right now anyway.
