[Bug c++/55095] Wshift-overflow

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |miyuki at gcc dot gnu.org

--- Comment #16 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #15)
> Yea, I'm afraid we'll have to do what you suggest.  And warn for the sign
> bit only when -Wshift-overflow=2.

Actually for me it looks like the correct way to handle this case. I mean, in
c-family/c-common.c we have:

/* Warn if signed left shift overflows.  We don't warn
   about left-shifting 1 into the sign bit in C++14; cf.
   <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3367.html#1457>
...

And this check is implemented like this:

  /* Handle the left-shifting 1 into the sign bit case.  */
  if (integer_onep (op0)
      && compare_tree_int (op1, prec0 - 1) == 0)

But in fact, even though the defect report explicitly mentions the "1 << x"
case, the resolution is more general. It says:

...if E1 has a signed type and non-negative value, and E1 ⨯ 2^E2 is
representable in the *corresponding unsigned type of the* result type, then
that *value, converted to the result type,* is the resulting value; otherwise,
the behavior is undefined.

I.e., we should not warn for (0x1f << 27) either, at least when compiling C++14
code. But it seems reasonable to use the same logic for earlier dialects of C++
and C when -Wshift-overflow=1, as it is done now.