From patchwork Mon Jan 20 15:08:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Monakov X-Patchwork-Id: 1226011 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-517797-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=ispras.ru Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha1 header.s=default header.b=jwjAp5Bw; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 481ZnK6Tc4z9sRk for ; Tue, 21 Jan 2020 02:08:53 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=kbTJasopyWSF0Gxin1F3BndGpPFyLKLxPhsHo97+O73q1BlanXG+N nSjBW5TzS93PEMxe7AWWGWYTvPi54HwOd8uVqtkHsVQaw3qP3WgDMkO+RmfcbMhH IwQqiv0p7rI8ZQZmxZ+/KoZTUanG0OgXEPJ0lwukQlEULtGQVNPtT8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=wDlN/CoXmThPEO+OzNMWrqtlV14=; b=jwjAp5Bwji6xuuW3TXh8 yZkrS3n8VHVYw9P2sNDXb+uykPd2B5dqym4KSTUjYjkAIYtfJ/FYCO2IJJlgUu6V eC7Gy7HVjb1TWBV4BjgXiMFoHEdEA6nYb7NXpxza5GSDjqeMccdvcl9STrgJep2R 6UxuVXL9DZHbudTPEGdZrls= Received: (qmail 21668 invoked by alias); 20 Jan 2020 15:08:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 21658 invoked by uid 89); 20 Jan 2020 15:08:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=sk:pointer, H*F:D*ru X-HELO: smtp.ispras.ru Received: from winnie.ispras.ru (HELO smtp.ispras.ru) (83.149.199.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Jan 2020 15:08:36 +0000 Received: from [10.10.3.121] (monopod.intra.ispras.ru [10.10.3.121]) by smtp.ispras.ru (Postfix) with ESMTP id 12D2B203BF for ; Mon, 20 Jan 2020 18:08:34 +0300 (MSK) Date: Mon, 20 Jan 2020 18:08:34 +0300 (MSK) From: Alexander Monakov To: gcc-patches@gcc.gnu.org Subject: [PATCH] doc: clarify the situation with pointer arithmetic Message-ID: User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 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