[Bug middle-end/35056] New: [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[Bug middle-end/35056] New: [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

Current trunk ICEs in building libqt4:

g++-4.3 -O -o /dev/null -S style.cpp 
rendering/RenderStyle.h: In member function 'void
WebCore::RenderStyle::setOutlineStyle(WebCore::EBorderStyle, bool)':
rendering/RenderStyle.h:1570: internal compiler error: in copy_to_mode_reg, at
explow.c:621
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.opensuse.org/> for instructions.


-- 
           Summary: [4.3 Regression] ICE in copy_to_mode_reg, at
                    explow.c:621
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: critical
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-02 12:27 -------
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.2.2
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-02 12:27 -------
Created an attachment (id=15076)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15076&action=view)
testcase (unincluded)


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

------- Comment #3 from matz at gcc dot gnu dot org  2008-02-02 15:52 -------
Reduced by hand:

% cat x.cc
enum EBorderStyle { bla = 1 };
template<typename T, typename U>
inline bool compareEqual(const T& t, const U& u)
{
  return t == u;
}
struct S {
  unsigned m_style : 4;
};

void call (S *s, EBorderStyle v)
{
  if (!compareEqual(s->m_style, v))
    s->m_style = v;
}

The problem is confusion between the bitmap type and promotion.  If you
rewrite the compare into a direct expression ("if (s->m_style != v) ...")
the error doesn't occur.  Anyway, as written this get's generated as
(004.gimple):

  <unnamed-unsigned:4> D.1670;
  unsigned char D.1673;
  unsigned int D.1668;

  D.1670 = s->m_style;
  D.1668 = D.1670;
  D.1671 = compareEqual (&D.1668, &v);
  retval.0 = !D.1671;

Note how s->m_style gets copied first into a unsigned:4, then into an unsigned
temp, which is given to compareEqual.  v (the enum) stays as is.  This gets
further expanded into (from 130.final_cleanup):

<bb 2>:
  if (s->m_style != v)

I.e. no conversions anymore.  But if we look at the expression which is tried
to be expanded to RTL:

do_compare_and_jump (exp=0xb7cb9438, ...
(gdb) p debug_tree (exp)
 <ne_expr 0xb7cb9438
   ...
   arg 0 <component_ref 0xb7cc0168
     type <integer_type 0xb7d46f08 public unsigned QI size <integer_cst
           0xb7cb4498 8> unit size <integer_cst 0xb7cb44b4 1>
           align 8 symtab 0 alias set -1 canonical type 0xb7d46f08
           precision 4
           min <integer_cst 0xb7d4b94c 0> max <integer_cst 0xb7d4b968 15>>
   arg 1 <parm_decl 0xb7cba820 v
        type <enumeral_type 0xb7d46888 EBorderStyle unsigned type_6 SI
            size <integer_cst 0xb7cb4620 constant invariant 32>
            unit size <integer_cst 0xb7cb440c constant invariant 4>

Note how the first argument has the bitfield type (4 bit precision) and
QImode, and the second argument is the enum type, which has SImode, precision
32 (but min/max being 0/1).

>From there everything goes down, because the RTL expander is not prepared
for compares of mismatching mode.  Simply noone checks if the arguments
have a different mode; it checks for VOIDmode of constants, and BLKmode, in
which case it also expects a size.  But if the mode is normal then it must
be the same for both operands.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenther at suse dot de]

------- Comment #4 from rguenther at suse dot de  2008-02-02 15:57 -------
Subject: Re:  [4.3 Regression] ICE in copy_to_mode_reg,
 at explow.c:621

On Sat, 2 Feb 2008, matz at gcc dot gnu dot org wrote:

> ------- Comment #3 from matz at gcc dot gnu dot org  2008-02-02 15:52 -------
> Reduced by hand:
> 
> % cat x.cc
> enum EBorderStyle { bla = 1 };
> template<typename T, typename U>
> inline bool compareEqual(const T& t, const U& u)
> {
>   return t == u;
> }
> struct S {
>   unsigned m_style : 4;
> };
> 
> void call (S *s, EBorderStyle v)
> {
>   if (!compareEqual(s->m_style, v))
>     s->m_style = v;
> }
> 
> The problem is confusion between the bitmap type and promotion.  If you
> rewrite the compare into a direct expression ("if (s->m_style != v) ...")
> the error doesn't occur.  Anyway, as written this get's generated as
> (004.gimple):
> 
>   <unnamed-unsigned:4> D.1670;
>   unsigned char D.1673;
>   unsigned int D.1668;
> 
>   D.1670 = s->m_style;
>   D.1668 = D.1670;

This is missing a conversion, type checking would complain.

Richard.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-02 16:06 -------
>From the .original dump:

;; Function void call(S*, EBorderStyle) (_Z4callP1S12EBorderStyle)
;; enabled by -tree-original


<<< Unknown tree: if_stmt
  <<cleanup_point !compareEqual ((const unsigned int &) (const unsigned int *)
&TARGET_EXPR <D.1668, s->m_style>, (const EBorderStyle &) (const EBorderStyle
*) &v)>>
  <<cleanup_point <<< Unknown tree: expr_stmt
  (void) (s->m_style = (<unnamed-unsigned:4>) (unsigned char) v) >>>
>>
   >>>
;

The TARGET_EXPR initializer already misses the conversion.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-02 16:06:33
               date|                            |


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

------- Comment #6 from matz at gcc dot gnu dot org  2008-02-02 16:08 -------
(written before richis comment, essentially the same info)

The compare routine doesn't need to be a template to show the bug.  But it
needs to take reference parameters.  The difference is in the call.  E.g.
with this testcase:

% cat x.cc
enum EBorderStyle { bla = 1 };
inline bool compare_ref(const unsigned int &t, const EBorderStyle &u)
{ return t == u; }
inline bool compare_val(const unsigned int t, const EBorderStyle u)
{ return t == u; }
struct S {
  unsigned m_style : 4;
};
void call_ref (S *s, EBorderStyle v)
{ if (!compare_ref(s->m_style, v)) s->m_style = v; }
void call_val (S *s, EBorderStyle v)
{ if (!compare_val(s->m_style, v)) s->m_style = v; }

The bodies of the two compare routines is sensible (after all nothing
fancy happens as not bitfield types are involved there anymore):

bool compare_ref(const unsigned int&, const EBorderStyle&) (t, u)
{
  bool D.1655;
  unsigned int D.1656;
  EBorderStyle D.1657;

  D.1656 = *t;
  D.1657 = *u;
  D.1655 = D.1656 == D.1657;
  return D.1655;
}
bool compare_val(unsigned int, EBorderStyle) (t, u)
{
  bool D.1662;

  D.1662 = t == u;
  return D.1662;
}

But the difference in the call setup is revealing:

void call_ref(S*, EBorderStyle) (s, v)
  <unnamed-unsigned:4> D.1672;
  unsigned int D.1670;
  ...
  D.1672 = s->m_style;
  D.1670 = D.1672;
  D.1673 = compare_ref (&D.1670, &v);
}

void call_val(S*, EBorderStyle) (s, v)
{
  ...
  <unnamed-unsigned:4> D.1682;
  unsigned int D.1683;
  ...
  D.1682 = s->m_style;
  D.1683 = (unsigned int) D.1682;
  D.1684 = compare_val (D.1683, v);
}

Note how the call with the reference parameter copies the value from the 
bitfield into an unsigned temp without a cast, and the call by value copies
it into a unsigned temp with a cast.  That latter cast will stay there until
130.final_cleanup, and hence the compare instruction will be expanded
correctly.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-02 16:15 -------
This

Index: tree.c
===================================================================
--- tree.c      (revision 132071)
+++ tree.c      (working copy)
@@ -417,6 +417,10 @@ build_target_expr_with_type (tree init, 
        aggregate; there's no additional work to be done.  */
     return force_rvalue (init);

+  if (INTEGRAL_TYPE_P (type)
+      || POINTER_TYPE_P (type))
+    init = fold_convert (type, init);
+
   return force_target_expr (type, init);
 }


fixes it.  It might be not the very best place for the fix though (and with
dependent arguments it might not be wise to call into the middle-end either).


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2008-02-02 16:16 -------
The TARGET_EXPR is built via

#0  build4_stat (code=TARGET_EXPR, tt=0xb7ce6340, arg0=0xb7ce0160, 
    arg1=0xb7ce10f0, arg2=0x0, arg3=0x0)
    at /home/richard/src/trunk/gcc/tree.c:3207
#1  0x0825c48e in build_target_expr (decl=0xb7ce0160, value=0xb7ce10f0)
    at /home/richard/src/trunk/gcc/cp/tree.c:262
#2  0x0825da09 in force_target_expr (type=0xb7ce6340, init=0xb7ce10f0)
    at /home/richard/src/trunk/gcc/cp/tree.c:435
#3  0x0825d9b3 in build_target_expr_with_type (init=0xb7ce10f0, 
    type=0xb7ce6340) at /home/richard/src/trunk/gcc/cp/tree.c:420
#4  0x080606dd in convert_like_real (convs=0x8e6968c, expr=0xb7ce10f0, 
    fn=0xb7d689a0, argnum=0, inner=0, issue_conversion_warnings=1 '\001', 
    c_cast_p=0 '\0') at /home/richard/src/trunk/gcc/cp/call.c:4510
#5  0x08063669 in build_over_call (cand=0x8e696d4, flags=3)
    at /home/richard/src/trunk/gcc/cp/call.c:4996
#6  0x08059170 in build_new_function_call (fn=0xb7d6ca48, args=0xb7d6c9f4, 
    koenig_p=1 '\001') at /home/richard/src/trunk/gcc/cp/call.c:2887
#7  0x0824ac2f in finish_call_expr (fn=0xb7d6ca48, args=0xb7d6c9f4, 
    disallow_virtual=0 '\0', koenig_p=1 '\001')
    at /home/richard/src/trunk/gcc/cp/semantics.c:1942


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2008-02-02 16:30 -------
The correct fix is probably here (convert_like_real):

            if ((lvalue & clk_packed)
                && CLASS_TYPE_P (type)
                && !TYPE_HAS_TRIVIAL_INIT_REF (type))
              {
                error ("cannot bind packed field %qE to %qT",
                       expr, ref_type);
                return error_mark_node;
              }
            expr = build_target_expr_with_type (expr, type);

and call convert_like_real (convs->u.next, expr ... with the right mysterious
arguments before passing the initializer to build_target_expr_with_type.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c++


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

------- Comment #10 from matz at gcc dot gnu dot org  2008-02-02 17:47 -------
A TARGET_EXPR has the following semantics:
(1) If it's a RHS of a MODIFY_STMT (or similar), i.e.:
       lhs = TARGET_EXPR<slot, init, cleanup>
    this is (for gimplifying) the same as
       lhs = init
    except when TREE_TYPE(init) is void, in that case the init tree is
    expected to magically set 'slot' when evaluated.
(2) If it's not the RHS of something, i.e. in a toplevel stmt for instance,
    then this is equivalent to:
       slot = init
    (again, except when 'init' has void type).

Let's ignore the case that 'init' has void type, then 'init' is an expression,
and the semantics of TARGET_EXPR are the same as
    temp = init

This is only valid when
  useless_type_conversion(TREE_TYPE(temp), TREE_TYPE(init)) .
Hence I think for all TARGET_EXPRs created, for which init hasn't void type,
the above predicate has to hold.  I think this is best ensured in the lowest
functions which create TARGET_EXPR, not in the high-level users.

Hence I think the safest would be to modify build_target_expr directly,
with something like this:

Index: cp/tree.c
===================================================================
--- cp/tree.c   (Revision 132064)
+++ cp/tree.c   (Arbeitskopie)
@@ -259,6 +259,11 @@ build_target_expr (tree decl, tree value
 {
   tree t;

+  if (!VOID_TYPE_P (TREE_TYPE (value))
+      && TREE_TYPE (decl) != TREE_TYPE (value)
+      && !useless_type_conversion_p (TREE_TYPE (decl), TREE_TYPE (value)))
+    value = fold_convert (TREE_TYPE (decl), value);
+
   t = build4 (TARGET_EXPR, TREE_TYPE (decl), decl, value,
              cxx_maybe_build_cleanup (decl), NULL_TREE);
   /* We always set TREE_SIDE_EFFECTS so that expand_expr does not


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2008-02-02 18:42 -------
Note that I think the FEs should not use the middle-end predicate but instead
use the more strict type equality as fold does.  But I'll leave that to the
FE maintainers to figure out what and where the best fix is for this.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

------- Comment #12 from jakub at gcc dot gnu dot org  2008-02-03 07:48 -------
In the FE usually no predicate is used, you just call fold_convert and it will
return the second argument if the types match, otherwise add NOP_EXPR or
whatever
is appropriate around it.
The question is just whether build_target_expr is the right spot to insert
the fold_convert, or whether it shouldn't be done in its callers.


-- 

jakub at gcc dot gnu dot org changed:

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


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

------- Comment #13 from matz at gcc dot gnu dot org  2008-02-04 11:48 -------
Yep, that's something the FE maintainers need to decide.  From a robustness
p.o.v. I'd do it in build_target_expr, though perhaps that has speed
implications.  FWIW the patch from comment #10 (with an added
"#include <tree-flow.h>" for the useless_type_conversion_p) regstrapped on
i686, x86_64 and ppc.


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2008-02-04 20:11 -------
Regression introduced by the call.c (reference_binding) changes from
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131751


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2008-02-04 20:43 -------
Either build_identity_conv (tfrom, expr) is wrong if tfrom != from
(the comment about build_identity_conv function suggest that I think), or
convert_like_real needs to fold_convert in the ck_identity case.
If the former, which conversion type needs to be used instead and won't it
affect
overload resolution?


-- 

jakub at gcc dot gnu dot org changed:

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


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[aoliva at gcc dot gnu dot org]

------- Comment #16 from aoliva at gcc dot gnu dot org  2008-02-05 03:35 -------
Jakub, build_identity_conv is correct, at least in this case.  In C++, the
bitfieldness :-) of a variable is not to be taken into account for purposes of
overload resolution.  So, when tfrom != from, this means it is an identity
conversion, but one that C++ represents internally using the variant bitfield
type, which leads to this sort of problem.

I'm a bit concerned about adding the type conversion to build_target_expr(),
because of the comment above force_target_expr():
/* Like the above function, but without the checking.  This function should
   only be used by code which is deliberately trying to subvert the type
   system, such as call_builtin_trap.  */

Forcing a conversion might break the deliberate expectations mentioned there,
although I can't see that such expectations are still present in the current
code.  There are only two callers of force_target_expr(), and I don't see that
either has anything to do with subverting the type system.

Anyhow, I think it might be more appropriate to add the type conversion to
build_target_expr_with_type(), which most of C++ uses anyway, and where the
desired type is explicitly specified.


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[mmitchel at gcc dot gnu dot org]

------- Comment #17 from mmitchel at gcc dot gnu dot org  2008-02-05 05:22 -------
I would suggest inserting the conversion right before the call to
build_target_expr_with_type in convert_like_real:

            if ((lvalue & clk_packed)
                && CLASS_TYPE_P (type)
                && !TYPE_HAS_TRIVIAL_INIT_REF (type))
              {
                error ("cannot bind packed field %qE to %qT",
                       expr, ref_type);
                return error_mark_node;
              }
            expr = build_target_expr_with_type (expr, type);

In particular, call:

  /* If EXPR is a bitfield, convert it to its declared type before
     building a TARGET_EXPR.  */
  expr = convert_bitfield_to_declared_type (expr);

You could do this somewhere in build_target_expr, but I think it's better to
leave those routines as low-level details.


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[aoliva at gcc dot gnu dot org]

------- Comment #18 from aoliva at gcc dot gnu dot org  2008-02-05 06:20 -------
Ugh.  I've just posted a patch that uses fold_convert at that very spot, and
then I saw your suggestion.  I'll re-test with that instead.


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[aoliva at gcc dot gnu dot org]

------- Comment #19 from aoliva at gcc dot gnu dot org  2008-02-06 20:32 -------
Subject: Bug 35056

Author: aoliva
Date: Wed Feb  6 20:31:43 2008
New Revision: 132158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132158
Log:
gcc/cp/ChangeLog:
PR c++/35056
* tree.c: Include tree-flow.h.
(build_target_expr): Check type compatibility.
* Make-lang.in (cp/tree.o): Depend on $(TREE_FLOW_H).
* call.c (convert_like_real): Convert bitfield to expected type.
gcc/testsuite/ChangeLog:
PR c++/35056
* g++.dg/conversion/bitfield8.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/conversion/bitfield8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/Make-lang.in
    trunk/gcc/cp/call.c
    trunk/gcc/cp/tree.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[aoliva at gcc dot gnu dot org]

------- Comment #20 from aoliva at gcc dot gnu dot org  2008-02-06 20:33 -------
Err, mine ;-)


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[aoliva at gcc dot gnu dot org]

------- Comment #21 from aoliva at gcc dot gnu dot org  2008-02-06 20:34 -------
Fixed


-- 

aoliva at gcc dot gnu dot org changed:

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


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