[Bug tree-optimization/89536] [8/9 Regression] wrong code at -Os and above on x86_64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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. :-)