From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12869 invoked by alias); 3 Mar 2014 16:12:39 -0000 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 Received: (qmail 12415 invoked by uid 48); 3 Mar 2014 16:12:33 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE Date: Mon, 03 Mar 2014 16:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg00192.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595 --- Comment #7 from Jakub Jelinek --- (In reply to Meador Inge from comment #5) > Created attachment 32253 [details] > Work in progress patch. > > Yeah, I am came to the same conclusion after making that comment that > removing the asserts is a bogus approach. > > Although, my follow up approach is a little different. I was trying to > replicate what we currently have in the 'movsi' pattern (see attached). > This seems to work for the basic tests I have tried. This patch is lightly > tested, is obviously in need of cleanup (since it duplicates code), and > doesn't cover the thumb case. I am just posting it for discussion purposes. > > Are we guaranteed to always have the const plus form? Or do we need to be > more general like in the patch I attached? It is good enough for i?86/x86_64, so I don't see why it wouldn't be for arm. Note, this is about what the middle-end is prepared to feed to emit_move_insn, I can't imagine it would feed something more complex than that. rs6000 has code similar to your case and has the assert in there too. Another alternative would be to have something like your patch, but do the check before the if (!TARGET_ARM) case in arm_legitimize_address and drop the TLS handling in thumb_legitimize_address to avoid the duplication. I wonder how it can work on thumb2 anyway without legitimizing TLS. BTW, the force_operand is perhaps unnecessary, but perhaps we should recurse into arm_legitimize_address instead, so that it takes care of out of range addends?