Jakub Jelinek <jakub at gcc dot> changed:

           What    |Removed                     |Added
                 CC|                            |jason at gcc dot,
                   |                            |jsm28 at gcc dot,
                   |                            |mpolacek at gcc dot

--- Comment #4 from Jakub Jelinek <jakub at gcc dot> ---
For C++ this regressed as expected with r230365 - in both cases delayed
Without delayed folding, e.g. (val16 & 0xffffffff) is folded into (unsigned
int) val16 by the time shorten_compare is called and that is the routine that
performs the warning.
Do we perform similar optimizations that shorten_compare does already in
match.pd or gimple-fold.c?
Would there be a better place to move the warning to (like in c_genericize or
Or, if we want to warn in shorten_compare, should it be done twice, once on the
unfolded values and then on folded values just for comparison purposes?
Conceptually, shorten_compare (except for the part where it computes the common
type for the comparison) is an optimization, kind of folding, so for delayed
folding should not be done early.  But if e.g. constexpr evaluation or
__builtin_constant_p etc. relies on it, it should conceptually be done at
c_fully_fold time.  Though, I think the warning needs to be done before we
shorten the compare and c_fully_fold shouldn't be performing warnings (because
it can be called multiple times, e.g. when trying to fold something for other
Thoughts on this?

Reply via email to