[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)

[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)

[steven at gcc dot gnu dot org]

------- Comment #9 from steven at gcc dot gnu dot org  2005-10-29 15:11 -------
I'm testing the patch from comment #8 on a few targets.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-08-02 20:57:12         |2005-10-29 15:11:43
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #10 from mmitchel at gcc dot gnu dot org  2005-10-31 04:37 -------
Leaving as P2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)

[bonzini at gcc dot gnu dot org]

------- Comment #11 from bonzini at gcc dot gnu dot org  2005-11-11 08:59 -------
Could the patch to lower pointer arithmetic to array arithmetic help?

typedef int int_array[];
typedef int_array *p_int_array;

int var;

void f()
{
  asm volatile ("" :: "i"(&(*(p_int_array)&var)[1]));
}


does not work too, but it looks like if the compiler did this lowering, it
would be valid GIMPLE and there would be no need to create the temporary.

And this would be doable at -O0 too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)

[bonzini at gcc dot gnu dot org]

------- Comment #12 from bonzini at gcc dot gnu dot org  2005-11-11 09:00 -------
CCing dberlin as he was the author of the pointer->array patch.


-- 

bonzini at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-01-14 05:50 -------
This seems like it should be higher than P2 as this is valid code and it is
rejected.  CCing Mark.  Also this was set P2 by default (before the default was
P3).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org, mmitchel at gcc dot gnu
                   |                            |dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2006-01-15 23:15 -------
This is valid code, but not particularly commonplace code.  Furthermore, it
doesn't look like we've got any good way to fix this -- except for the patch in
Comment #8.  What were the results of the testing mentioned in Comment #9?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[steven at gcc dot gnu dot org]

------- Comment #15 from steven at gcc dot gnu dot org  2006-01-15 23:22 -------
I don't recall the results of testing this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[amacleod at redhat dot com]

------- Comment #16 from amacleod at redhat dot com  2006-01-19 19:50 -------
Created an attachment (id=10678)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10678&action=view)
updated patch

I updated the patch to the current mainline, and  have built and verified no
additional failures on i686-pc-linux-gnu.  I suspect it is safe, but I am also
doing a full bootstrap now. 


-- 

amacleod at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9523 is|0                           |1
           obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mrs at apple dot com]

------- Comment #17 from mrs at apple dot com  2006-02-04 00:16 -------
I've found a way to fix this at -O0 for my code with something like:

  /* APPLE LOCAL begin CW asm blocks */
  {
    tree array = ptrop;
    STRIP_NOPS (array);

    /* We want to canonicalize PLUS_EXPR into ARRAY_REF for data
       pointers as ARRAY_REFs can be converted into RTL code without
       introducing additional temporaries when not optimizing, which
       is useful as otherwise when all registers are in use by the
       assembly code, we can run reload out of registers.  */

    if (inside_cw_asm_block
        && flag_ms_asms
        && resultcode == PLUS_EXPR
        && TREE_CODE (array) == ADDR_EXPR
        && !(TREE_CODE (TREE_TYPE (TREE_TYPE (array))) == FUNCTION_TYPE
             || TREE_CODE (TREE_TYPE (TREE_TYPE (array))) == METHOD_TYPE))
      {
        tree type;
        tree r;
        tree new_i;

        size_exp = convert (TREE_TYPE (intop), size_exp);

        /* We have to ensure that when ARRAY_REF is used, it will
           calculate the offset correctly as it is element based, and we
           are byte based.  */
        new_i = fold (build_binary_op (CEIL_DIV_EXPR, intop, size_exp, 1));
        if (build_binary_op (MULT_EXPR, new_i, size_exp, 1) == intop)
          {
            array = TREE_OPERAND (array, 0);
            type = TREE_TYPE (TREE_TYPE (array));
            if (TREE_CODE (type) != ARRAY_TYPE)
              type = TYPE_MAIN_VARIANT (type);
            r = build4 (ARRAY_REF, type, array, new_i, NULL_TREE, NULL_TREE);
            TREE_READONLY (r)
              |= (TYPE_READONLY (TREE_TYPE (TREE_TYPE (array)))
                  | TREE_READONLY (array));
            TREE_SIDE_EFFECTS (r)
              |= (TYPE_VOLATILE (TREE_TYPE (TREE_TYPE (array)))
                  | TREE_SIDE_EFFECTS (array));
            TREE_THIS_VOLATILE (r)
              |= (TYPE_VOLATILE (TREE_TYPE (TREE_TYPE (array)))
                  /* This was added by rms on 16 Nov 91.
                     It fixes  vol struct foo *a;  a->elts[1]
                     in an inline function.
                     Hope it doesn't break something else.  */
                  | TREE_THIS_VOLATILE (array));
            r = fold (r);
            r = build1 (ADDR_EXPR, result_type, r);
            r = fold (r);
            return r;
          }
      }
  }

inside pointer_int_sum just before:

  /* Replace the integer argument with a suitable product by the object size.
     Do this multiplication as signed, then convert to the appropriate
     pointer type (actually unsigned integral).  */

  intop = convert (result_type,
                   build_binary_op (MULT_EXPR, intop,
                                    convert (TREE_TYPE (intop), size_exp), 1));

This makes it though gimple without creating any decls and makes it through rtl
expansion without creating any new pseduo registers when using an "m"
constraint and putting an INDIRECT_REF on it.

You can see this working on the apple-local-200502-branch, Radar 4399388.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #18 from mmitchel at gcc dot gnu dot org  2006-02-24 00:26 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.1.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mrs at apple dot com]

------- Comment #19 from mrs at apple dot com  2006-02-24 02:14 -------
This was not 4.1.0 before, it was 4.0.3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mark at codesourcery dot com]

------- Comment #20 from mark at codesourcery dot com  2006-02-24 02:17 -------
Subject: Re:  [4.0/4.1/4.2 regression] rejects "i"(&var
 + 1)

mrs at apple dot com wrote:
> ------- Comment #19 from mrs at apple dot com  2006-02-24 02:14 -------
> This was not 4.1.0 before, it was 4.0.3.

Yes.  I will still know it is a 4.0 issue because of the subject line.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[stsp at users dot sourceforge dot net]

------- Comment #21 from stsp at users dot sourceforge dot net  2006-05-13 08:27 -------
Hi guys.

A question: are there any hopes to get this to work with -fpic?
I mean, even the "i"(&var) doesn't work with -fpic.
The "info gcc" says that all the constant addresses are resolved
by the dynamic linker if -fpic is used. So I wonder, why can't
it resolve also the addresses that are used inside the asm() block?
Am I missing something obvious, or it is a bug too?


-- 

stsp at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stsp at users dot
                   |                            |sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #22 from mmitchel at gcc dot gnu dot org  2006-05-25 02:33 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[jakub at gcc dot gnu dot org]

------- Comment #23 from jakub at gcc dot gnu dot org  2006-10-04 22:20 -------
"i"(&var) of course can't work with -fpic, it would only work at the expense
of text relocations, but those are not allowed on some architectures and highly
undesirable on the rest of architectures.  In position independent code,
&var typically means you need to load that address from global offset table
into a register, and a register of course can't satisfy "i" constraint.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[amacleod at redhat dot com]

------- Comment #24 from amacleod at redhat dot com  2006-10-04 22:33 -------
The updated version of TER that will go into 4.3 during stage 1 resolves this
problem... TER no longer tracks dependencies the way it use to. It will replace
the expression, resulting in:

main ()
{
<bb 2>:
  __asm__ __volatile__(""::"i" &var + 1B);
  return 0;

}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[stsp at users dot sourceforge dot net]

------- Comment #25 from stsp at users dot sourceforge dot net  2006-10-05 19:29 -------
> "i"(&var) of course can't work with -fpic,
I tried it on an x86_64 today, and it seems to work.
If I use -m32, then it doesn't. Why?

> it would only work at the expense
> of text relocations, but those are not allowed on some architectures and
> highly undesirable on the rest of architectures.
Is this to always keep the .text section r/o?

> In position independent code,
> &var typically means you need to load that address from global offset table
So, as I understand your answer, the relocation at dynamic-link time
is not implemented at all (even on the arches where it is possible)?

> into a register, and a register of course can't satisfy "i" constraint.
Thanks for the hint. It looks like the things like "a"(&var) do
work with -fpic, which should be fine for my needs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[amacleod at redhat dot com]

------- Comment #26 from amacleod at redhat dot com  2006-12-08 14:32 -------
The new version of TER was just checked into mainline. This should resolve this
bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #27 from mmitchel at gcc dot gnu dot org  2007-03-10 01:36 -------
Andrew indicates that this is fixed in 4.3 in this message:

http://gcc.gnu.org/ml/gcc/2007-03/msg00249.html


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression]
                   |rejects "i"(&var + 1)       |rejects "i"(&var + 1)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)

[mmitchel at gcc dot gnu dot org]

------- Comment #28 from mmitchel at gcc dot gnu dot org  2007-03-10 01:40 -------
In this message:

http://gcc.gnu.org/ml/gcc/2007-03/msg00249.html

Andre Macleod indicates that this will be difficult to fix in pre-4.3
compilers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[pinskia at gcc dot gnu dot org]

------- Comment #29 from pinskia at gcc dot gnu dot org  2007-03-10 01:41 -------
(In reply to comment #27)
> Andrew indicates that this is fixed in 4.3 in this message:
Actually it was only fixed with optimization turned on.  It still fails at -O0.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1/4.2 regression]    |[4.0/4.1/4.2/4.3 regression]
                   |rejects "i"(&var + 1)       |rejects "i"(&var + 1)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[amacleod at redhat dot com]

------- Comment #30 from amacleod at redhat dot com  2007-03-12 13:11 -------
Err, yeah. thats right. TER doesn't run without optimization, and I forgot this
was more than just an optimization issue.  Where is that work to do basic SSA
optimizations at -O0 when you need it?? :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[jakub at gcc dot gnu dot org]

------- Comment #31 from jakub at gcc dot gnu dot org  2007-11-22 15:41 -------
Could we perhaps for !optimize allow in ASM input operands arbitrary
tree expressions if TREE_CONSTANT for operands which !allows_mem &&
!allows_reg?
Then we'd just need to make sure the few -O0 passes are able to cope with it
and adjust gimplifier to do that and verification to accept that.
For -O0 expecting
int i = 1;
asm ("" :: "i" (i));
to work is certainly bad assumption, so it is enough to preserve what the user
used in the inline asm.  I guess only nesting and omp passes would care, those
can transform a valid "i" operand into invalid one.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[jakub at gcc dot gnu dot org]

------- Comment #32 from jakub at gcc dot gnu dot org  2007-11-22 15:52 -------
Or alternatively make sure to gimplify all inputs which allow reg or mem
first, then gimplify those that don't allow either, which for -O0 should
hopefully mean all such expressions stay in the same basic block as the asm
and then if (!optimize) in expand_gimple_basic_block look at asm inputs and
if some of them doesn't allow mem nor reg and is gimple register, walk back
to find definitions within the bb and reconstruct the expression (kind of very
lame TER alternative) and stop whenever some of the used gimple reg definitions
can't be found, or once it is not TREE_CONSTANT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)

[stsp at users dot sourceforge dot net]

------- Comment #33 from stsp at users dot sourceforge dot net  2007-11-22 17:27 -------
> For -O0 expecting
> int i = 1;
> asm ("" :: "i" (i));
> to work is certainly bad assumption
Btw, even the
static const int i = 1;
asm ("" :: "i" (i));
doesn't work with both -O0 and -O1. :(


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2008-01-16 22:23 -------
We should possibly split this bug into two, one for the inconsitencies that
can be observed with accepted asms comparing -O0 to -O and one for the
bug that we reject(ed) "i"(&var + 1) with optimization.

Or declare the latter as fixed (and wontfix on the branches) and turn this
into a bug about the first issue.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1/4.2/4.3 regression]|[4.1/4.2/4.3 Regression]
                   |rejects "i"(&var + 1)       |rejects "i"(&var + 1)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[stsp at users dot sourceforge dot net]

------- Comment #35 from stsp at users dot sourceforge dot net  2008-01-17 18:43 -------
(In reply to comment #34)
> We should possibly split this bug into two, one for the inconsitencies that
> can be observed with accepted asms comparing -O0 to -O and one for the
Done.
I opened Bug 34830, Bug 34832, and, just
in case, Bug 34833 (the later is probably not
a bug).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[jsm28 at gcc dot gnu dot org]

------- Comment #36 from jsm28 at gcc dot gnu dot org  2008-07-04 20:00 -------
Closing 4.1 branch.  Since the last comment indicates this bug was split into
other bugs (all of which have been closed), unsetting milestone and closing
this bug.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.1.3                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[stsp at users dot sourceforge dot net]

------- Comment #37 from stsp at users dot sourceforge dot net  2008-07-05 05:28 -------
But I only tried to open the new bugs about
the _other_ -O0 vs -O2 differences that popped
up in this thread.
The original bug is still here I believe.
At least it seems people think it should work
with -O0 too, which right now it does not.


-- 

stsp at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[jsm28 at gcc dot gnu dot org]

------- Comment #38 from jsm28 at gcc dot gnu dot org  2008-07-05 09:40 -------
Removing 4.1 marker and restoring milestone in that case.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
                   |rejects "i"(&var + 1)       |rejects "i"(&var + 1)
   Target Milestone|---                         |4.2.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[rguenth at gcc dot gnu dot org]

------- Comment #39 from rguenth at gcc dot gnu dot org  2009-01-25 18:39 -------
Even with SSA at -O0 now and forcefully trying to enable TER with -ftree-ter
the testcase still fails.  So, re-confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-06-18 05:52:02         |2009-01-25 18:39:58
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[amacleod at redhat dot com]

------- 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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #41 from jsm28 at gcc dot gnu dot org  2009-03-31 18:54 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression]
                   |rejects "i"(&var + 1)       |rejects "i"(&var + 1)
   Target Milestone|4.2.5                       |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[rguenth at gcc dot gnu dot org]

------- Comment #42 from rguenth at gcc dot gnu dot org  2009-08-04 12:26 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[rguenth at gcc dot gnu dot org]

------- Comment #43 from rguenth at gcc dot gnu dot org  2010-05-22 18:10 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200

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

[pinskia at gcc dot gnu dot org]

------- Comment #44 from pinskia at gcc dot gnu dot org  2010-08-18 22:42 -------
*** Bug 45303 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jobnoorman at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200