https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > We do take the range as granted in both cases. If for BIT_NOT_EXPR on say > int the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure. > If the result is any other value, then we run into the impossible territory, > if previous optimizations did a good job, then likely that comparison should > have been folded away, but what if it appeared since the last pass that > could have optimized it away? So this is about potential pessimization instead of correctness here? > Normally I'd say the _4 == -5 comparison would be optimized to 0 because _4 > has RANGE [-2, -1]. If for whatever reason it is not, then I think it is > better to keep status quo in the dominated code. Why? The default code would compute a totally bogus value. > I guess your TREE_INT_CST_LOW & 1 hunk is probably still desirable for the > Ada > boolean case (or we fix match.pd and drop this altogether at some point). As > the patch has been applied to 8.3.1, we have a serious regression and need a > fix > fast though. OK, I'm going to apply the (TREE_INT_CST_LOW & 1) fixlet as it is obviously more correct than the current code. Then we can keep arguing for a while. :-)
