On 1/20/20 8:08 AM, Alexander Monakov wrote:
Hi,
we have this paragraph in the documentation that attempts to prohibit something
that is allowed by the language. Instead, I think we should say that this
generally should work and explain that a problem in GCC implementation
breaks this.
OK to apply?
Thanks.
Alexander
* doc/implement-c.texi (Arrays and Pointers): Rewrite the paragraph
about pointer-as-integer arithmetic.
diff --git a/gcc/doc/implement-c.texi b/gcc/doc/implement-c.texi
index 692297b69c4..beee2510670 100644
--- a/gcc/doc/implement-c.texi
+++ b/gcc/doc/implement-c.texi
@@ -401,11 +401,15 @@ pointer representation is smaller than the integer type,
extends according
to the signedness of the integer type if the pointer representation
is larger than the integer type, otherwise the bits are unchanged.
-When casting from pointer to integer and back again, the resulting
-pointer must reference the same object as the original pointer, otherwise
-the behavior is undefined. That is, one may not use integer arithmetic to
-avoid the undefined behavior of pointer arithmetic as proscribed in
-C99 and C11 6.5.6/8.
+Arithmetic on integers derived from pointers can produce a value such
+that casting it back produces a valid pointer corresponding to one of
+the original pointers. Thus, integer arithmetic allows to express
+computations that might not be expressible as pointer arithmetic without
+undefined behavior. However, at a certain point the distinction between
+pointers and integers is lost (when GCC translates from GIMPLE internal
+representation to RTL), but some optimizations still attempt to track
+pointer arithmetic beyond that point. In some cases this may cause
+valid code to be incorrectly optimized.
@item
@cite{The size of the result of subtracting two pointers to elements
I'm not happy with this -- we shouldn't be talking about internal
concepts like GIMPLE and RTL in the GCC user manual. Can we instead
talk about which user-visible optimization options cause problems, so
that users who feel the urgent need to write hacky code like that know
what to disable? (I'd guess it would be things involving alias
analysis.) Otherwise, I think we should stick with the current "don't
do this" language or some variant of it that explains briefly that,
while such code is technically allowed by the C standard, it confuses
GCC's optimizers.
-Sandra
