[Bug target/39139] New: [4.4 Regression] ICE with stringop and register var

[Bug target/39139] New: [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

static inline int
foo (unsigned int x, void *y)
{
  register unsigned long r asm ("rax");
  register unsigned long a1 asm ("rdi") = a1;
  register unsigned long a2 asm ("rsi") = a2;
  a1 = (unsigned long) x;
  a2 = (unsigned long) y;
  asm volatile ("" : "=r" (r), "+r" (a1), "+r" (a2) : : "memory");
  return (int) r;
}

struct T { unsigned long t1, t2; unsigned int t3, t4, t5; };

int
bar (unsigned long x, unsigned int y, unsigned long u, unsigned int v)
{
  long r;
  struct T e = { .t1 = x, .t2 = u };

  if (x << y != u << v)
    return 5;
  r = foo (11, &e);
  return e.t3 == x;
}

distilled from xen ICEs at -Os, DIREG class register isn't available.  First
appeared between r134096 and r134467, not IRA related.


-- 
           Summary: [4.4 Regression] ICE with stringop and register var
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.4.0
      Known to work|                            |4.3.2
           Priority|P3                          |P1
   Target Milestone|---                         |4.4.0


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2009-02-09 16:39 -------
Regression since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134321
tree-ssa-sink.c moves e = {} store across a1 = 11 initialization, where a1
is a register asm ("%rdi") variable, so into a spot where %rdi is live and thus
can't be used for rep; stos*.  Not sure what we should do.  i386 expander
avoids using stos* etc. when %rdi is a global reg variable or fixed register,
but doesn't have df info to find out that %rdi is just locally live across this
spot.  Probably it would be better not to sink that store across register var
initialization.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-09 16:45 -------
This would be a fragile solution.  I think the backend has to cope with that
in some way, for example not using string expanders when there is any local
register variable.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-09 16:53 -------
Another option is RESOLVED INVALID.  Whoever uses local fixed regs ...


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2009-02-09 18:12 -------
... must do what exactly?  Using DECL_HARD_REGISTER vars in macros or inline
functions is very common, starting from kernel, glibc, many programs that
invoke syscalls directly, etc., and it worked well until now.
I think sinking = {} across DECL_HARD_REGISTER initialization is wrong even if
we teach i386 backend about DECL_HARD_REGISTER vars and don't use the stringop
insns in that case.  something = {} might expand into memset call, and for all
call-clobbered vals having a call when those are live is definitely a bug.
All macros/inlines that use DECL_HARD_REGISTER vars I remember first prepare
all arguments in normal vars and then only copy everything to the hard
registers, so it can be only the compiler reordering stuff that introduces
breakage.  Optimizations that increase the live range of such variables need to
be avoided.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2009-02-09 19:12 -------
I think it is related to PR 38941. 


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #6 from hjl dot tools at gmail dot com  2009-02-09 19:39 -------
I think gcc treats REG in:

register unsigned long reg asm ("rax");

as an alias of the RAX register. If you use REG in any
way which interferes with register allocator, you will
get either ICE or unexpected results.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2009-02-09 20:17 -------
This is different from that PR.  In this case the code does nothing dangerous
in the block with the register vars.  For %rdi and a couple of other regs on
x86-64
one could actually use "D" etc. constraints, but r8-r15 already don't have a
single register class for each register, and on most of the other targets this
isn't available either.  So just to show that this isn't x86-64 only issue,
here is a testcase for sparc64-linux:
static inline int
foo (unsigned int x, void *y)
{
  register unsigned long r asm ("o0");
  register unsigned long a1 asm ("g1") = a1;
  register unsigned long a2 asm ("g5") = a2;
  a1 = (unsigned long) x;
  a2 = (unsigned long) y;
  asm volatile ("# %0 %1 %2" : "=r" (r), "+r" (a1), "+r" (a2) : : "memory");
  return (int) r;
}

struct T { unsigned long t1, t2; unsigned int t3, t4, t5; };

int
bar (unsigned long x, unsigned int y, unsigned long u, unsigned int v)
{
  long r;
  struct T e = { .t1 = x, .t2 = u };

  if (x << y != u << v)
    return 5;
  r = foo (11, &e);
  return e.t3 == x;
}

compile with -Os -m64 and -Os -m64 -fno-tree-sink.  See in the latter:
        add     %fp, 2015, %l0
        mov     0, %o1
        mov     %l0, %o0
        call    memset, 0
         mov    32, %o2
...
        mov     %l0, %g5
        mov     11, %g1
#APP
! 9 "pr39139.c" 1
        # %o0 %g1 %g5
#NO_APP

I.e. it would work just fine, both are initialized to the expected value.  With
sinking we have:
        save    %sp, -208, %sp
        sllx    %i0, %i1, %i1
        sllx    %i2, %i3, %i3
        cmp     %i1, %i3
        bne,pt  %xcc, .LL3
         mov    5, %g1
        add     %fp, 2015, %o0
        mov     0, %o1
        call    memset, 0
         mov    32, %o2
        stx     %i2, [%fp+2023]
        stx     %i0, [%fp+2015]
#APP
! 9 "mm.c" 1
        # %o0 %g1 %g5
#NO_APP
where neither g1 nor g5 are initialized at all (they were initialized during
expand, but before the memset call, and as both g1 and g5 are call clobbered
their value would (or could) be corrupted during the call anyway).

I'd say easiest fix would be for tree-ssa-sink.c to punt sinking = {} if there
are any DECL_HARD_REGISTER vars in the function.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]



------- Comment #8 from hjl dot tools at gmail dot com  2009-02-09 20:29 -------
[hjl@gnu-6 reg-1]$ cat b.c
extern void abort (void);
int g = 3;

int main()
{
    register int x __asm__("ecx");
    x = 5;
    if ((1 << g) != 8 || x != 5)
      abort ();
    return 0;
}
[hjl@gnu-6 reg-1]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -m32 -O0  b.c -S -o b.s
b.c: In function ‘main’:
b.c:11: error: unable to find a register to spill in class ‘CREG’
b.c:11: error: this is the insn:
(insn 8 7 9 2 b.c:8 (parallel [
            (set (reg:SI 0 ax [orig:60 D.1254 ] [60])
                (ashift:SI (reg:SI 1 dx [63])
                    (subreg:QI (reg:SI 0 ax [orig:61 g.0 ] [61]) 0)))
            (clobber (reg:CC 17 flags))
        ]) 495 {*ashlsi3_1} (expr_list:REG_DEAD (reg:SI 1 dx [63])
        (expr_list:REG_DEAD (reg:SI 0 ax [orig:61 g.0 ] [61])
            (expr_list:REG_UNUSED (reg:CC 17 flags)
                (nil)))))
b.c:11: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-6 reg-1]$ 

My point is if you use "register unsigned long reg asm" on local
variables, you may run into ICE or unexpected results if the
register you specified happens to be used by compiler for
some basic operations.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #9 from hjl dot tools at gmail dot com  2009-02-09 20:32 -------
We should take a look at the problem "register unsigned long reg asm"
trying to resolve. We may need to provide some other reliable ways
to address the problem.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jeremy at goop dot org]

------- Comment #10 from jeremy at goop dot org  2009-02-09 20:35 -------
The code in question is setting up parameters for a Xen hypercall.  The
hypercall ABI defines what arguments go in which registers.  It uses the
"register unsigned long arg asm" syntax because that's the only way to specify
high registers on x86-64.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2009-02-09 20:36 -------
Sure, but in your testcase you do the operation that requires the register
while the register var is still in scope and live.  The compiler doesn't have a
possibility to compile it right.  But, if we say it is ok for the compiler to
move an unrelated 1 << somevar or call, stringop etc. into a block where the
register var is live and ICE because the compiler did it, we'd basically forbid
all uses of register vars.  Automatic register vars are there mainly to support
inline asm hardcoded inputs/outputs for which you don't have special register
classes, programmers using them know very well the limitations and that they
only copy prepared stuff from other variables into the register variables, do
inline asm and copy back the results from local register vars to other vars.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jeremy at goop dot org]

------- Comment #12 from jeremy at goop dot org  2009-02-09 20:37 -------
Created an attachment (id=17274)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17274&action=view)
Original code to set up hypercalls.

This is the original code Jakub distilled the reproducer from.  It includes a
comment containing the rationale for the way the code is structured.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #13 from hjl dot tools at gmail dot com  2009-02-09 20:41 -------
(In reply to comment #10)
> The code in question is setting up parameters for a Xen hypercall.  The
> hypercall ABI defines what arguments go in which registers.  It uses the
> "register unsigned long arg asm" syntax because that's the only way to specify
> high registers on x86-64.
> 

I suspected that is what happened. PR 38925 is another case.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |38925


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2009-02-09 20:43 -------
PR 16331 is another.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |16331


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #15 from hjl dot tools at gmail dot com  2009-02-09 20:44 -------
I tempted to reopen PR 16331 and mark PR 38925/39139 as dup
for PR 16331.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #16 from hjl dot tools at gmail dot com  2009-02-09 20:46 -------


*** This bug has been marked as a duplicate of 16331 ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2009-02-09 20:49 -------
This is wrong, this is not a dup of PR16331.  PR16331 is invalid, it makes a
call with r8 in scope.  This one doesn't.  That's pretty substantial
difference.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org,
                   |                            |drepper at redhat dot com
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #18 from hjl dot tools at gmail dot com  2009-02-09 20:52 -------
(In reply to comment #17)
> This is wrong, this is not a dup of PR16331.  PR16331 is invalid, it makes a
> call with r8 in scope.  This one doesn't.  That's pretty substantial
> difference.
> 

PR 16331 is "x86-64 inline asm register constraints insufficient WRT ABI".
Isn't this the same problem here?


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #19 from jakub at gcc dot gnu dot org  2009-02-09 21:01 -------
No.  This bug is about all targets, not just x86-64, and is about code which
follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
years (glibc e.g. uses it this way for more than 10 years).  Do you suddenly
want to rule all that code invalid?
See glibc INLINE_SYSCALL and INTERNAL_SYSCALL macros on all arches, Linux
asm*/unistd.h _syscall* macros until very recently, etc.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #20 from hjl dot tools at gmail dot com  2009-02-09 21:09 -------
(In reply to comment #19)
> No.  This bug is about all targets, not just x86-64, and is about code which
> follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
> years (glibc e.g. uses it this way for more than 10 years).  Do you suddenly
> want to rule all that code invalid?
> See glibc INLINE_SYSCALL and INTERNAL_SYSCALL macros on all arches, Linux
> asm*/unistd.h _syscall* macros until very recently, etc.
> 

If you don't get ICE, you don't have to change anything. If
you do get ICE, you may have to update.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[ian at airs dot com]

------- Comment #21 from ian at airs dot com  2009-02-09 22:37 -------
I agree with Jakub that the original test case, and the one in comment #7,
appear to conform to the documented gcc extension.  I think that gcc has to
treat this sort of code as valid, and not break it.  We can't casually or
accidentally break our documented extensions.

Unfortunately this means that in a function which contains both local register
variables and an asm, we must severely restrict any code motion which may
involve a function call or the use of hidden registers.  We should explicitly
express a dependency between any asm and any local register variable in scope
for the asm.  That won't solve the problem by itself, though.


-- 

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[hjl dot tools at gmail dot com]

------- Comment #22 from hjl dot tools at gmail dot com  2009-02-10 01:36 -------
I guess it is too expensive to add a new reg class for each
register to support constraints for all registers.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[bonzini at gnu dot org]

------- Comment #23 from bonzini at gnu dot org  2009-02-10 09:50 -------
> I guess it is too expensive to add a new reg class for each
> register to support constraints for all registers.

This has no reference to the actual problem of this PR.

The sparc testcase that Jakub posted is particularly significative, since you
don't get ICEs but wrong code there.

> Unfortunately this means that in a function which contains both local register
> variables and an asm, we must severely restrict any code motion which may
> involve a function call or the use of hidden registers.

I think that in the GIMPLE grammar local register variables should be treated
as memory, with loads and stores separated from the computations; and just like
memory, each asm or function call should have a VUSE and (depending on the
asm's inputs, outputs and clobbers; and in the case of function calls for
call-clobbered local register variables) VDEF for the local register variables.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-02-10 09:50:44
               date|                            |


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2009-02-10 10:20 -------
Their loads and stores are already separated from other computations, as
they aren't is_gimple_reg.  And they do have VDEFs/VUSES:
  # a1D.1284_24 = VDEF <a1D.1284_23(D)> { a1D.1284 }
  a1D.1284 = 11;
  y.0D.1287_15 = (long unsigned intD.4) &eD.1268;
  # a2D.1285_26 = VDEF <a2D.1285_25(D)> { a2D.1285 }
  a2D.1285 = y.0D.1287_15;
  # eD.1268_28 = VDEF <eD.1268_22>
  # rD.1283_29 = VDEF <rD.1283_27(D)>
  # a1D.1284_30 = VDEF <a1D.1284_24>
  # a2D.1285_31 = VDEF <a2D.1285_26> { eD.1268 rD.1283 a1D.1284 a2D.1285 }
  __asm__ __volatile__("" : "=r" rD.1283, "=r" a1D.1284, "=r" a2D.1285 : "1"
a1D.1284 : "2" a2D.1285 : "memory");

But that is not enough to prevent sinking in between these, sinking of e = {}
looks solely at eD.1268_* VUSEs and the immediate user is therefore the asm.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2009-02-10 10:29 -------
Created an attachment (id=17275)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17275&action=view)
gcc44-pr39139.patch

Quick patch to avoid sinking of block copies or clearings if current function
has local explicit register vars.  If there are other passes that move around
calls or potential calls to places where they haven't been originally, they
could do similar thing.  If needed, we could track which basic blocks have such
vars live etc., but I don't think it is worth it.

The alternative would be to make DECL_HARD_REGISTER initializations (and uses?)
act like loads/stores of pointers that can point to any memory, but that seems
to me even bigger overkill, there is nothing wrong with moving a normal memory
load or store, it is just the potential libcalls and inline stringops that are
a problem.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2009-02-10 10:35 -------
I could imagine that other architectures have other special registers, so
I think treating them like pointer dereferences to anything would be more
robust than changing all code-motion passes.


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[bonzini at gnu dot org]

------- Comment #27 from bonzini at gnu dot org  2009-02-10 10:49 -------
The patch does not seem too bad.  You could add a target hook to get a
HARD_REG_SET or constituting an optimization barriers (defaulting to all
call-clobbered registers, which would be okay for all targets that do not have
stringops).


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #28 from jakub at gcc dot gnu dot org  2009-02-10 16:22 -------
Subject: Bug 39139

Author: jakub
Date: Tue Feb 10 16:22:29 2009
New Revision: 144065

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144065
Log:
        PR target/39139
        * function.h (struct function): Add has_local_explicit_reg_vars
        bit.
        * gimplify.c (gimplify_bind_expr): Set it if local DECL_HARD_REGISTER
        VAR_DECLs were seen.
        * tree-ssa-live.c (remove_unused_locals): Recompute
        cfun->has_local_explicit_reg_vars.
        * tree-ssa-sink.c (statement_sink_location): Don't sink BLKmode
        copies or clearings if cfun->has_local_explicit_reg_vars.

        * gcc.target/i386/pr39139.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr39139.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/function.h
    trunk/gcc/gimplify.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-live.c
    trunk/gcc/tree-ssa-sink.c


-- 


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

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

[jakub at gcc dot gnu dot org]

------- Comment #29 from jakub at gcc dot gnu dot org  2009-02-10 16:35 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

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


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