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.