From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23273 invoked by alias); 8 Nov 2012 17:18:01 -0000 Received: (qmail 23167 invoked by uid 48); 8 Nov 2012 17:17:38 -0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88 Date: Thu, 08 Nov 2012 17:18:00 -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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00744.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #27 from Eric Botcazou 2012-11-08 17:17:35 UTC --- > No, this would be one giant kludge by itself. The failure just shows that the > controversial patch [1] for PR 49721 was wrong. > > Quote from [1]: > > --quote-- > I am checking in this patch, which only affects x32 > and nothing else. This one character change, from > > POINTERS_EXTEND_UNSIGNED < 0 > > to > > POINTERS_EXTEND_UNSIGNED != 0 > > creates a working x32 GCC. This isn't perfect. I have > tried many different approaches without any success. > I will revisit it if we run into any problems with x32 > applications. > --/qoute-- > > So, we run into problem. It's not totally wrong, given the context of convert_memory_address_addr_space which is already optimistically correct only. The problem is that the case POINTERS_EXTEND_UNSIGNED > 0 is trickier than POINTERS_EXTEND_UNSIGNED == 0 because RTL constants are sign-extended: in the latter case, everything is sign-extended so this is symmetric and simple; in the former case, one part is zero-extended and the other part sign-extended and, in order to make this work under the same hypothesis of non-overflow, one would need to know which part is bigger. In the case at hand, the code would be correct if the constant was zero-extended and the register sign-extended, not the reverse as currently.