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?
