From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 79716385DC35; Fri, 26 Jun 2020 11:03:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79716385DC35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1593169397; bh=L2lNz7qmIayXYRCwA5KXicKTqZkBiSS6GGEYvvG53jQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IFJgmuy97RKm7L5222FzJBFqivg9+lzRe+n/n+uI2phRjA7meKQwIjAiXtG2ib3lS fg7e2mWL9GVYUB+0TaROgej0Ma/G5vRdzv5JjKwpIABYhy2l0qlJjAHnu9b1hpE0lp RdaiQzdrU4LpgyEkQU9JRrOKAfcZHW8mD4ZBT8z8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/95903] gcc 10: wrong code with -fwrapv Date: Fri, 26 Jun 2020 11:03:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 11:03:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95903 --- Comment #7 from Jakub Jelinek --- I believe all arrays larger than half of the address space are outside of t= he standard already, one can't perform e.g. address arithmetics on those becau= se it overflows the ptrdiff_t in which it is evaluated. It has been discussed in other PRs. I don't know about aarch64 ilp32, but for several arches with 64-bit hw pointers either the hw has some addressing mode that ignores the upper bits (e.g. zero or sign extends addresses during access), or often the AS is even limited to just half of the size, so that both sign and zero extension beha= ve the same. If you believe there is a problem for aarch64, please file a separate PR and the people familiar with that target needs to discuss it, certainly it is unrelated to this, because at GIMPLE the sources just contain pointers and pointers are 32-bit for these, so there is no extension at that level. It = is just the backend driven extensions depending on POINTERS_EXTEND_UNSIGNED (n= ot defined at all, the usual case when ptr_mode =3D=3D Pmode, 1 for zero exten= sion, 0 for sign extension and -1 for special instructions to perform it).=