[Bug inline-asm/23200] [4.2/4.3/4.4 Regression] rejects "i"(&var + 1)

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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  <jh@suse.cz>
  (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