From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5544 invoked by alias); 26 Jan 2009 16:17:01 -0000 Received: (qmail 5306 invoked by uid 48); 26 Jan 2009 16:16:43 -0000 Date: Mon, 26 Jan 2009 16:17:00 -0000 Message-ID: <20090126161643.5305.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug inline-asm/23200] [4.2/4.3/4.4 Regression] rejects "i"(&var + 1) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amacleod at redhat dot com" 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: 2009-01/txt/msg02836.txt.bz2 ------- Comment #40 from amacleod at redhat dot com 2009-01-26 16:16 ------- Created an attachment (id=17185) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17185&action=view) possible patch The problem is due to a check that was added to is_replaceable_p() in tree-ssa-ter.c. I presume this was added by Honza back in 2008-07-19 Jan Hubicka (is_replaceable_p): Check that locations match; when aliasing is missing be conservative about loads. The check is: if (!optimize && ((locus1 && locus1 != locus2) || (block1 && block1 != block2))) return false; The locus's do not compare equal. This is presumably due to Aldy's enhanced column information which can easily create different locus's for things that are on the same line. I presume this check is an attempt to preserve debug information at some level by not merging expressions from different lines? Honza will have to verify this assumption. I'm also unsure about why blocks for the locus's are compared at the end of the expression. There is a check to make sure the 2 expressions are in the same block a few lines above, so why the locus block check as well? Shouldn't just locus comparing be sufficient? In any case, if the locus block's are not checked, and the locus line numbers are compared if *both* are valid, then the test case work. With -ftree-ter of course. Honza will have to comment on the intent and rationale however, there may be other reasons for that code. A secondary question, why is TER turned off by default with this check in place? It shouldn't destroy any critical debug info if only things that originated on the same line are merged... And on that note, I've added making TER not lose locus's high on my todo list. There is nothing inherent in it that would lose locus info, so I'm presuming there is an oversight in there somewhere. IS that the only problem with TER as far as -O0 goes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200