[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I'm getting lost in what convert does though with the TREE_OVERFLOW
flag.
In the testcase, we have a cast of BIT_IOR_EXPR with (whatever, 0x80) and 0 int
arguments to unsigned char.
do_narrow is called and does:
      /* Don't do unsigned arithmetic where signed was wanted,
         or vice versa.
         Exception: if both of the original operands were
         unsigned then we can safely do the work as unsigned.
         Exception: shift operations take their type solely
         from the first argument.
         Exception: the LSHIFT_EXPR case above requires that
         we perform this operation unsigned lest we produce
         signed-overflow undefinedness.
         And we may need to do it as unsigned
         if we truncate to the original size.  */
and as BIT_IOR_EXPR isn't listed, type == typex is unsigned and TREE_TYPE
(arg0) and TREE_TYPE (arg1) are signed goes the:
          if (TYPE_UNSIGNED (typex))
            typex = signed_type_for (typex);
way.  Those conversions create TYPE_OVERFLOW constant, even when there was
nothing wrong in the source and because of the COMPOUND_EXPRs in there we don't
manage to optimize those TYPE_OVERFLOW constants away and warn on it.

For BIT_AND_EXPR/BIT_IOR_EXPR/BIT_XOR_EXPR, I must say I miss the reason why
it would be ever a good idea to use typex = signed_type_for (typex), when we
want unsigned result, just converting to that right away doesn't have any
downsides I can come up with.
But I wonder even about the other operations, do we really want to introduce
TYPE_OVERFLOWs in such cases where the operations are originally on wider
signed operands and are cast to some narrower unsigned type?