GCC's -fwrapv option does not affect code generation for shifts
because currently GCC does not rely on the fact that certain
signed shifts trigger undefined behavior. However, the definition
of signed arithmetic overflow does extend to shifts; it is only
code generation that is limited to addition, subtraction and
multiplication.
Make the documentation of -fwrapv consistent with the existing
text under -fstrict-overflow ("Using '-fwrapv' means that integer
signed overflow is fully defined: it wraps.").
Ok for trunk, and for GCC 5 branch after 5.3 is released?
Paolo
* doc/implement-c.texi (Integers Implementation): Make GCC's promises
about signed left shift stronger and clarify the cases when they're
broken.
Index: doc/implement-c.texi
===================================================================
--- doc/implement-c.texi (revision 230466)
+++ doc/implement-c.texi (working copy)
@@ -266,9 +266,11 @@
immediately above the highest-value value bit. Signed @samp{>>} acts
on negative numbers by sign extension.
-GCC does not use the latitude given in C99 and C11 only to treat certain
-aspects of signed @samp{<<} as undefined, but this is subject to
-change.
+As an extension to the C language, GCC does not use the latitude given in
+C99 and C11 only to treat certain aspects of signed @samp{<<} as undefined.
+However, @option{-fsanitize=shift} (and @option{-fsanitize=undefined}) will
+diagnose such cases. They are also diagnosed where constant
+expressions are required.
@item
@cite{The sign of the remainder on integer division (C90 6.3.5).}
