[Bug c++/40321] New: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[Bug c++/40321] New: internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

This is with GCC trunk, revision 148003:

...
[ 69%] Building CXX object
CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/HTTP.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/Networking.o
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In
function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const
LX56ProjAttribs&, const CVec&, const CVec&, CWorm*, TimeDiff,
ProjCollisionType)':
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129:
internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o]
Fehler 1
make[2]: *** Warte auf noch nicht beendete Prozesse...


-- 
           Summary: internal compiler error: in compute_antic, at tree-ssa-
                    pre.c:2501
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ich at az2000 dot de
  GCC host triplet: amd64
GCC target triplet: amd64


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

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #1 from ich at az2000 dot de  2009-06-01 14:40 -------
Sorry, it was revision 148004.

I also tried with rev 148039, same error:

/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In
function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const
LX56ProjAttribs&, const CVec&, const CVec&, CWorm*, TimeDiff,
ProjCollisionType)':
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp:129:
internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #2 from ich at az2000 dot de  2009-06-01 14:50 -------
The specific file which fails has a lot of inline code, perhaps that is the
reason for failing. There are certain reasons why we want to have that inline.

This is the file if you want to take a look:
http://openlierox.svn.sourceforge.net/viewvc/openlierox/src/common/PhysicsLX56_Projectiles.cpp?view=markup

I guess it cannot really be reproduced with a simple example as the problem is
probably the complexitiy here.


-- 


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

[Bug c++/40321] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #3 from ich at az2000 dot de  2009-06-01 16:34 -------
I have commented out the check in tree-ssa-pre.c:2501, and then, after eating
up about 8GB memory (that was all available), I got this:

c++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Btw., I have some similar problem with GCC 4.4.0. It's also eating up all
memory there and dies in the end, for the same source file. It doesn't occur
with GCC 4.3 though.


-- 


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

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|c++                         |tree-optimization
           Keywords|                            |ice-on-valid-code
            Summary|internal compiler error: in |[4.5 Regression] internal
                   |compute_antic, at tree-ssa- |compiler error: in
                   |pre.c:2501                  |compute_antic, at tree-ssa-
                   |                            |pre.c:2501
   Target Milestone|---                         |4.5.0
            Version|tree-ssa                    |4.5.0


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

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #4 from ich at az2000 dot de  2009-06-01 16:52 -------
Created an attachment (id=17941)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17941&action=view)
source file after preprocessor

I just created the temporary source file (via -save-temps) and attached it.


-- 


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

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #5 from ich at az2000 dot de  2009-06-01 18:02 -------
Perhaps that was anyway clear from the report, but I didn't noted the most
important point directly: The problem occurs only with -O3. If I don't set a
specific optimisation, it works.


-- 


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

[Bug tree-optimization/40321] [4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-06-02 10:23 -------
At -O1 -ftree-pre I get

src/common/PhysicsLX56_Projectiles.cpp: In function 'ProjCollisionType
LX56_simulateProjectile_LowLevel(AbsTime, TimeDiff, CProjectile*, const
LX56ProjAttribs&, CWorm*, bool*, bool*)':
src/common/PhysicsLX56_Projectiles.cpp:1156:33: internal compiler error: in
vn_reference_lookup_3, at tree-ssa-sccvn.c:1174

instead.

Reducing the -O2 ICE and then the other one.


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.5 Regression] internal   |[4.4/4.5 Regression]
                   |compiler error: in          |internal compiler error: in
                   |compute_antic, at tree-ssa- |compute_antic, at tree-ssa-
                   |pre.c:2501                  |pre.c:2501
   Target Milestone|4.5.0                       |4.4.1


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-06-02 13:55 -------
Confirmed.  Reduced testcase:

struct VectorD2
{
    VectorD2() : x(0), y(0) { }
    VectorD2(int _x, int _y) : x(_x), y(_y) { }
    int x, y;
    int GetLength2() const { return x*x + y*y; };
    VectorD2 operator+(const VectorD2 vec) const { 
        return VectorD2(x+vec.x,y+vec.y);
    }
};
struct Shape 
{
  enum Type { ST_RECT, ST_CIRCLE } type;
  VectorD2 pos;
  VectorD2 radius;
  bool CollisionWith(const Shape& s) const;
};
bool Shape::CollisionWith(const Shape& s) const
{
  if(type == ST_CIRCLE && s.type == ST_RECT)
    return s.CollisionWith(*this);
  return (pos + s.pos).GetLength2() < (radius + s.radius).GetLength2();
}


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-02 13:55:12
               date|                            |


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2009-06-02 14:45 -------
Pffft.  Not this again...

<bb 3>:
  # this_2 = PHI <this_45(D)(2), s_4(7)>
  # s_4 = PHI <s_39(D)(2), this_2(7)>

so this_2 and s_4 are equal on one edge but not on another.  copyprop is
not always able to remove the PHI for some un-obvious reason.

Thus, how do we deal with that?

We enter PRE with

<bb 2>:

<bb 3>:
  # this_2 = PHI <this_45(D)(2), s_4(7)>
  # s_4 = PHI <s_39(D)(2), this_2(7)>
  D.2149_3 = this_2->type;
  if (D.2149_3 == 1)
    goto <bb 4>;
  else
    goto <bb 6>;

<bb 6>:
  goto <bb 5>;

<bb 4>:
  D.2152_5 = s_4->type;
  if (D.2152_5 == 0)
    goto <bb 7>;
  else
    goto <bb 8>;

<bb 7>:
  goto <bb 3>;

<bb 8>:

<bb 5>:
  # this_61 = PHI <this_2(6), this_2(8)>
  # s_62 = PHI <s_4(6), s_4(8)>
...

and have

Value numbers:
this_61 = this_2
s_62 = s_4

copy-prop seems confused:

Simulating statement (from ssa_edges): this_61 = PHI <this_2(3), this_2(4)>

Visiting PHI node: this_61 = PHI <this_2(3), this_2(4)>

PHI node this_61 copy-of chain: this_61 -> this_61 [NOT A COPY]
Telling the propagator to add SSA edges out of this PHI and never visit again.

but, before we fix copy-prop we probably should deal with this in PRE
by simply not phi_translating in circles.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-06-02 13:55:12         |2009-06-02 14:45:08
               date|                            |


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2009-06-02 15:04 -------
More reduced testcase, the loop is produced by tail-recursion:

struct Shape
{
  enum Type { ST_RECT, ST_CIRCLE } type;
  int pos;
  int CollisionWith(const Shape& s) const;
};
int Shape::CollisionWith(const Shape& s) const
{
  if(type == ST_CIRCLE && s.type == ST_RECT)
    return s.CollisionWith(*this);
  return (pos + s.pos);
}


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-06-02 15:21 -------
C testcase:

struct X { int type; int pos; };
int foo(struct X *a, struct X *b)
{
again:
  if (a->type == 0)
    goto out;
  if (b->type == 1)
    goto out;
  ({ struct X *tmp = a; a = b; b = tmp; });
  goto again;

out:
  return a->pos + b->pos;
}

"fix":

@@ -1734,6 +1767,19 @@ phi_translate_1 (pre_expr expr, bitmap_s
            if (TREE_CODE (def) == SSA_NAME)
              def = VN_INFO (def)->valnum;

+           /* If we translated the name to one defined by a PHI node
+              in the same basic-block punt.  This hints at cyclic
+              PHI nodes like
+              <bb 3>:
+                # this_2 = PHI <this_45(D)(2), s_4(4)>
+                # s_4 = PHI <s_39(D)(2), this_2(4)>
+              which can cause antic computation to never finis.  */
+           if (TREE_CODE (def) == SSA_NAME
+               && (def_stmt = SSA_NAME_DEF_STMT (def)) != NULL
+               && gimple_code (def_stmt) == GIMPLE_PHI
+               && gimple_bb (def_stmt) == phiblock)
+             return NULL;
+
            /* Handle constant. */
            if (is_gimple_min_invariant (def))
              return get_or_alloc_expr_for_constant (def);


Danny - any opinions here?


-- 

rguenth 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=40321

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2009-06-02 15:46 -------
Even simpler testcase:

struct X { int flag; int pos; };
int foo(struct X *a, struct X *b)
{
  while (1)
    {
      if (a->flag)
        break;
      ({ struct X *tmp = a; a = b; b = tmp; });
    }

  return a->pos + b->pos;
}


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-06-03 14:00 -------
The problem seems to be the asymmetry wrt handling of NAMEs vs. SSA_NAME
operands
in NARYs and REFERENCEs.  We happily translate NAMEs and do not clean them
if they are in AVAIL_OUT, but we only can translate SSA_NAME operands if they
have a leader in the set we are currently translating (wtf?) and we clean
the NARYs and REFERENCEs that do not have their SSA_NAME operands in ANTIC_IN
itself.

Huh.  Fixing both "fixes" the problem, but obviously results in larger ANTIC_IN
sets.

@@ -1466,13 +1499,15 @@ phi_translate_1 (pre_expr expr, bitmap_s
              {
                unsigned int op_val_id = VN_INFO (newnary.op[i])->value_id;
                pre_expr leader = find_leader_in_sets (op_val_id, set1, set2);
-               pre_expr result = phi_translate_1 (leader, set1, set2,
+               pre_expr result;
+               if (!leader)
+                 leader = get_or_alloc_expr_for_name (newnary.op[i]);
+               result = phi_translate_1 (leader, set1, set2,
                                                   pred, phiblock, seen);
                if (result && result != leader)
                  {
                    tree name = get_representative_for (result);
-                   if (!name)
-                     return NULL;
+                   gcc_assert (name != NULL_TREE);
                    newnary.op[i] = name;
                  }
                else if (!result)
@@ -1569,13 +1604,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
              {
                unsigned int op_val_id = VN_INFO (op0)->value_id;
                leader = find_leader_in_sets (op_val_id, set1, set2);
+               if (!leader)
+                 leader = get_or_alloc_expr_for_name (op0);
                opresult = phi_translate_1 (leader, set1, set2,
                                            pred, phiblock, seen);
                if (opresult && opresult != leader)
                  {
                    tree name = get_representative_for (opresult);
-                   if (!name)
-                     break;
+                   gcc_assert (name != NULL_TREE);
                    op0 = name;
                  }
                else if (!opresult)
@@ -1587,13 +1623,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
              {
                unsigned int op_val_id = VN_INFO (op1)->value_id;
                leader = find_leader_in_sets (op_val_id, set1, set2);
+               if (!leader)
+                 leader = get_or_alloc_expr_for_name (op1);
                opresult = phi_translate_1 (leader, set1, set2,
                                            pred, phiblock, seen);
                if (opresult && opresult != leader)
                  {
                    tree name = get_representative_for (opresult);
-                   if (!name)
-                     break;
+                   gcc_assert (name != NULL_TREE);
                    op1 = name;
                  }
                else if (!opresult)
@@ -1604,13 +1641,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
              {
                unsigned int op_val_id = VN_INFO (op2)->value_id;
                leader = find_leader_in_sets (op_val_id, set1, set2);
+               if (!leader)
+                 leader = get_or_alloc_expr_for_name (op2);
                opresult = phi_translate_1 (leader, set1, set2,
                                            pred, phiblock, seen);
                if (opresult && opresult != leader)
                  {
                    tree name = get_representative_for (opresult);
-                   if (!name)
-                     break;
+                   gcc_assert (name != NULL_TREE);
                    op2 = name;
                  }
                else if (!opresult)
@@ -2091,7 +2129,7 @@ clean (bitmap_set_t set, basic_block blo

   for (i = 0; VEC_iterate (pre_expr, exprs, i, expr); i++)
     {
-      if (!valid_in_sets (set, NULL, expr, block))
+      if (!valid_in_sets (set, AVAIL_OUT (block), expr, block))
        bitmap_remove_from_set (set, expr);
     }
   VEC_free (pre_expr, heap, exprs);


the fix results in some ICEs because we cannot insert though.

A fix the other way around is be possible as well, but it doesn't fix the
problem:

Index: tree-ssa-pre.c
===================================================================
--- tree-ssa-pre.c      (revision 148119)
+++ tree-ssa-pre.c      (working copy)
@@ -1717,6 +1717,10 @@ phi_translate_1 (pre_expr expr, bitmap_s
        edge e;
        gimple def_stmt;
        tree name = PRE_EXPR_NAME (expr);
+       unsigned int name_val_id = VN_INFO (name)->value_id;
+       pre_expr leader = find_leader_in_sets (name_val_id, set1, set2);
+       if (!leader)
+         return NULL;

        def_stmt = SSA_NAME_DEF_STMT (name);
        if (gimple_code (def_stmt) == GIMPLE_PHI
@@ -2006,7 +2010,7 @@ valid_in_sets (bitmap_set_t set1, bitmap
   switch (expr->kind)
     {
     case NAME:
-      return bitmap_set_contains_expr (AVAIL_OUT (block), expr);
+      return union_contains_value (set1, set2, get_expr_value_id (expr));
     case NARY:
       {
        unsigned int i;


Note that what is odd is that during clean () we use ANTIC_IN to clean
expressions but we change it at the same time.  How are we sure that
clean (); clean () is a no-op?


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[dberlin at dberlin dot org]

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



------- Comment #13 from dberlin at gcc dot gnu dot org  2009-06-03 15:16 -------
Subject: Re:  [4.4/4.5 Regression] internal 
        compiler error: in compute_antic, at tree-ssa-pre.c:2501

Hmmm, clean should only have to check set1 and set2, not AVAIL_OUT.
I'm not sure why it looks at AVAIL_OUT at all, that seems broken to me.

Gotta look at the change history to see what or if i was thinking

In reality, the behavior of translating names only if they have a
leader in the set we are currently translating is correct (or at least
is what the paper does and what "should" work).  Though if there is no
leader, it should actually return NULL_TREE, not keep going.  If there
is no leader for the name in ANTIC, the expression can't be ANTIC
since it's operands aren't ANTIC.  clean is probably removing those
anyway.

Anyway the GVNPRE theory goes:

Names get removed from ANTIC through subtraction of TMP_GEN only.

clean() clean() is a no-op because we do it in topological order
(sorted_array_from_bitmap), and thus are guaranteed to process names
before things dependent on those names.

On Wed, Jun 3, 2009 at 10:00 AM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #12 from rguenth at gcc dot gnu dot org  2009-06-03 14:00 -------
> The problem seems to be the asymmetry wrt handling of NAMEs vs. SSA_NAME
> operands
> in NARYs and REFERENCEs.  We happily translate NAMEs and do not clean them
> if they are in AVAIL_OUT, but we only can translate SSA_NAME operands if they
> have a leader in the set we are currently translating (wtf?) and we clean
> the NARYs and REFERENCEs that do not have their SSA_NAME operands in ANTIC_IN
> itself.
>
> Huh.  Fixing both "fixes" the problem, but obviously results in larger ANTIC_IN
> sets.
>
> @@ -1466,13 +1499,15 @@ phi_translate_1 (pre_expr expr, bitmap_s
>              {
>                unsigned int op_val_id = VN_INFO (newnary.op[i])->value_id;
>                pre_expr leader = find_leader_in_sets (op_val_id, set1, set2);
> -               pre_expr result = phi_translate_1 (leader, set1, set2,
> +               pre_expr result;
> +               if (!leader)
> +                 leader = get_or_alloc_expr_for_name (newnary.op[i]);
> +               result = phi_translate_1 (leader, set1, set2,
>                                                   pred, phiblock, seen);
>                if (result && result != leader)
>                  {
>                    tree name = get_representative_for (result);
> -                   if (!name)
> -                     return NULL;
> +                   gcc_assert (name != NULL_TREE);
>                    newnary.op[i] = name;
>                  }
>                else if (!result)
> @@ -1569,13 +1604,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
>              {
>                unsigned int op_val_id = VN_INFO (op0)->value_id;
>                leader = find_leader_in_sets (op_val_id, set1, set2);
> +               if (!leader)
> +                 leader = get_or_alloc_expr_for_name (op0);
>                opresult = phi_translate_1 (leader, set1, set2,
>                                            pred, phiblock, seen);
>                if (opresult && opresult != leader)
>                  {
>                    tree name = get_representative_for (opresult);
> -                   if (!name)
> -                     break;
> +                   gcc_assert (name != NULL_TREE);
>                    op0 = name;
>                  }
>                else if (!opresult)
> @@ -1587,13 +1623,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
>              {
>                unsigned int op_val_id = VN_INFO (op1)->value_id;
>                leader = find_leader_in_sets (op_val_id, set1, set2);
> +               if (!leader)
> +                 leader = get_or_alloc_expr_for_name (op1);
>                opresult = phi_translate_1 (leader, set1, set2,
>                                            pred, phiblock, seen);
>                if (opresult && opresult != leader)
>                  {
>                    tree name = get_representative_for (opresult);
> -                   if (!name)
> -                     break;
> +                   gcc_assert (name != NULL_TREE);
>                    op1 = name;
>                  }
>                else if (!opresult)
> @@ -1604,13 +1641,14 @@ phi_translate_1 (pre_expr expr, bitmap_s
>              {
>                unsigned int op_val_id = VN_INFO (op2)->value_id;
>                leader = find_leader_in_sets (op_val_id, set1, set2);
> +               if (!leader)
> +                 leader = get_or_alloc_expr_for_name (op2);
>                opresult = phi_translate_1 (leader, set1, set2,
>                                            pred, phiblock, seen);
>                if (opresult && opresult != leader)
>                  {
>                    tree name = get_representative_for (opresult);
> -                   if (!name)
> -                     break;
> +                   gcc_assert (name != NULL_TREE);
>                    op2 = name;
>                  }
>                else if (!opresult)
> @@ -2091,7 +2129,7 @@ clean (bitmap_set_t set, basic_block blo
>
>   for (i = 0; VEC_iterate (pre_expr, exprs, i, expr); i++)
>     {
> -      if (!valid_in_sets (set, NULL, expr, block))
> +      if (!valid_in_sets (set, AVAIL_OUT (block), expr, block))
>        bitmap_remove_from_set (set, expr);
>     }
>   VEC_free (pre_expr, heap, exprs);
>
>
> the fix results in some ICEs because we cannot insert though.
>
> A fix the other way around is be possible as well, but it doesn't fix the
> problem:
>
> Index: tree-ssa-pre.c
> ===================================================================
> --- tree-ssa-pre.c      (revision 148119)
> +++ tree-ssa-pre.c      (working copy)
> @@ -1717,6 +1717,10 @@ phi_translate_1 (pre_expr expr, bitmap_s
>        edge e;
>        gimple def_stmt;
>        tree name = PRE_EXPR_NAME (expr);
> +       unsigned int name_val_id = VN_INFO (name)->value_id;
> +       pre_expr leader = find_leader_in_sets (name_val_id, set1, set2);
> +       if (!leader)
> +         return NULL;
>
>        def_stmt = SSA_NAME_DEF_STMT (name);
>        if (gimple_code (def_stmt) == GIMPLE_PHI
> @@ -2006,7 +2010,7 @@ valid_in_sets (bitmap_set_t set1, bitmap
>   switch (expr->kind)
>     {
>     case NAME:
> -      return bitmap_set_contains_expr (AVAIL_OUT (block), expr);
> +      return union_contains_value (set1, set2, get_expr_value_id (expr));
>     case NARY:
>       {
>        unsigned int i;
>
>
> Note that what is odd is that during clean () we use ANTIC_IN to clean
> expressions but we change it at the same time.  How are we sure that
> clean (); clean () is a no-op?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-06-18 15:38 -------
Danny, any news here?


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[dberlin at dberlin dot org]

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



------- Comment #15 from dberlin at gcc dot gnu dot org  2009-06-18 15:48 -------
Subject: Re:  [4.4/4.5 Regression] internal 
        compiler error: in compute_antic, at tree-ssa-pre.c:2501

No, still trying to figure it out.
It's quite tricky.


On Thu, Jun 18, 2009 at 11:38 AM, rguenth at gcc dot gnu dot
org<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #14 from rguenth at gcc dot gnu dot org  2009-06-18 15:38 -------
> Danny, any news here?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[reichelt at gcc dot gnu dot org]

------- Comment #16 from reichelt at gcc dot gnu dot org  2009-06-30 02:15 -------
Even shorter testcase:

====================================
struct A
{
  bool b;
  int i;
  bool foo(const A& a) const;
};

bool A::foo(const A& a) const
{
  if (b)
    return a.foo(*this);
  return i < a.i;
}
====================================


-- 

reichelt at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2009-07-15 08:32 -------
Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2
   Target Milestone|4.4.1                       |4.4.2


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[ich at az2000 dot de]

------- Comment #18 from ich at az2000 dot de  2009-07-15 11:31 -------
Will this workaround-patch be included in 4.4.1? Because otherwise the whole
4.4.1 release will be pretty much useless for me.


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenther at suse dot de]

------- Comment #19 from rguenther at suse dot de  2009-07-15 11:33 -------
Subject: Re:  [4.4/4.5 Regression] internal
 compiler error: in compute_antic, at tree-ssa-pre.c:2501

On Wed, 15 Jul 2009, ich at az2000 dot de wrote:

> ------- Comment #18 from ich at az2000 dot de  2009-07-15 11:31 -------
> Will this workaround-patch be included in 4.4.1? Because otherwise the whole
> 4.4.1 release will be pretty much useless for me.

Unlikely.  You can use -fno-tree-pre as a workaround.

Richrd.


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2009-07-15 12:42 -------
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs).  Adding PHI arguments to the maximal set fixes this
PR...

Index: tree-ssa-pre.c
===================================================================
--- tree-ssa-pre.c      (revision 149663)
+++ tree-ssa-pre.c      (working copy)
@@ -3662,6 +3662,16 @@ make_values_for_phi (gimple phi, basic_b
       add_to_value (get_expr_value_id (e), e);
       bitmap_insert_into_set (PHI_GEN (block), e);
       bitmap_value_insert_into_set (AVAIL_OUT (block), e);
+      if (!in_fre)
+       {
+         unsigned i;
+         for (i = 0; i < gimple_phi_num_args (phi); ++i)
+           {
+             e = get_or_alloc_expr_for (gimple_phi_arg_def (phi, i));
+             add_to_value (get_expr_value_id (e), e);
+             bitmap_value_insert_into_set (maximal_set, e);
+           }
+       }
     }
 }


I'll give this a complete round of bootstrapping / testing.

Danny - does this look like an obvious mistake or are they not supposed to
be in the maximal set?


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2009-07-15 12:54 -------
Correction - only b_2 is missing from the maximal set, a_1 is there because
it is used in non-PHI nodes.  The fix indeed looks quite obvious to me now ...

For reference, here is the function before PRE again:

<bb 2>:

<bb 3>:
  # a_1 = PHI <a_3(D)(2), b_2(6)>
  # b_2 = PHI <b_4(D)(2), a_1(6)>
  D.1251_5 = a_1->flag;
  if (D.1251_5 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 6>:
  goto <bb 3>;

<bb 5>:

<bb 4>:
  # a_14 = PHI <a_1(5)>
  # b_15 = PHI <b_2(5)>
  D.1254_10 = a_14->pos;
  D.1255_11 = b_15->pos;
  D.1253_12 = D.1255_11 + D.1254_10;
  return D.1253_12;


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[dberlin at dberlin dot org]

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



------- Comment #22 from dberlin at gcc dot gnu dot org  2009-07-15 13:37 -------
Subject: Re:  [4.4/4.5 Regression] internal 
        compiler error: in compute_antic, at tree-ssa-pre.c:2501

Phi uses can be in the maximum set as long as they are not phi's themselves.
There is a comment above add_to_exp_gen that explains why:
" PHI nodes can't go in the maximal sets because they are not in
   TMP_GEN, so it is possible to get into non-monotonic situations
   during ANTIC calculation, because it will *add* bits. "

(being an intersection problem, the number of values in the set should
only ever stay the same or decrease)

I would be surprised if it bootstraps :)

On Wed, Jul 15, 2009 at 8:42 AM, rguenth at gcc dot gnu dot
org<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #20 from rguenth at gcc dot gnu dot org  2009-07-15 12:42 -------
> One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
> have the default defs).  Adding PHI arguments to the maximal set fixes this
> PR...
>
> Index: tree-ssa-pre.c
> ===================================================================
> --- tree-ssa-pre.c      (revision 149663)
> +++ tree-ssa-pre.c      (working copy)
> @@ -3662,6 +3662,16 @@ make_values_for_phi (gimple phi, basic_b
>       add_to_value (get_expr_value_id (e), e);
>       bitmap_insert_into_set (PHI_GEN (block), e);
>       bitmap_value_insert_into_set (AVAIL_OUT (block), e);
> +      if (!in_fre)
> +       {
> +         unsigned i;
> +         for (i = 0; i < gimple_phi_num_args (phi); ++i)
> +           {
> +             e = get_or_alloc_expr_for (gimple_phi_arg_def (phi, i));
> +             add_to_value (get_expr_value_id (e), e);
> +             bitmap_value_insert_into_set (maximal_set, e);
> +           }
> +       }
>     }
>  }
>
>
> I'll give this a complete round of bootstrapping / testing.
>
> Danny - does this look like an obvious mistake or are they not supposed to
> be in the maximal set?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[dberlin at dberlin dot org]

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



------- Comment #23 from dberlin at gcc dot gnu dot org  2009-07-15 13:46 -------
Subject: Re:  [4.4/4.5 Regression] internal 
        compiler error: in compute_antic, at tree-ssa-pre.c:2501

a_1 shouldn't be in the maximal set. If it is, that's a bug.

The history here:

We didn't use to have a check for domination in avail_out.
As a result, values only died if they were in TMP_GEN.
(This is what is *supposed* to happen. At some point we added a check
for availability to valid_in_sets and i can't remember why).
PHI values are not in TMP_GEN, so they will never disappear from the
set once in it.

Nowadays, it may be safe to put phi values in there.
Honestly, the availability check in valid_in_sets worries me, because
it shouldn't be necessary.
Names should be prevented from being ANTIC past the point of their
definition through subtraction of TMP_GEN.


On Wed, Jul 15, 2009 at 8:54 AM, rguenth at gcc dot gnu dot
org<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #21 from rguenth at gcc dot gnu dot org  2009-07-15 12:54 -------
> Correction - only b_2 is missing from the maximal set, a_1 is there because
> it is used in non-PHI nodes.  The fix indeed looks quite obvious to me now ...
>
> For reference, here is the function before PRE again:
>
> <bb 2>:
>
> <bb 3>:
>  # a_1 = PHI <a_3(D)(2), b_2(6)>
>  # b_2 = PHI <b_4(D)(2), a_1(6)>
>  D.1251_5 = a_1->flag;
>  if (D.1251_5 != 0)
>    goto <bb 5>;
>  else
>    goto <bb 6>;
>
> <bb 6>:
>  goto <bb 3>;
>
> <bb 5>:
>
> <bb 4>:
>  # a_14 = PHI <a_1(5)>
>  # b_15 = PHI <b_2(5)>
>  D.1254_10 = a_14->pos;
>  D.1255_11 = b_15->pos;
>  D.1253_12 = D.1255_11 + D.1254_10;
>  return D.1253_12;
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenther at suse dot de]

------- Comment #24 from rguenther at suse dot de  2009-07-15 13:58 -------
Subject: Re:  [4.4/4.5 Regression] internal
 compiler error: in compute_antic, at tree-ssa-pre.c:2501

On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:

> ------- Comment #23 from dberlin at gcc dot gnu dot org  2009-07-15 13:46 -------
> Subject: Re:  [4.4/4.5 Regression] internal 
>         compiler error: in compute_antic, at tree-ssa-pre.c:2501
> 
> a_1 shouldn't be in the maximal set. If it is, that's a bug.

D.1251_5 = a_1->flag;

so it's even in exp_gen.  And because a_1 is in the maximal set
b_2 has to.

Well, as you asy - we'll see if it bootstraps ;)

> The history here:
> 
> We didn't use to have a check for domination in avail_out.
> As a result, values only died if they were in TMP_GEN.
> (This is what is *supposed* to happen. At some point we added a check
> for availability to valid_in_sets and i can't remember why).
> PHI values are not in TMP_GEN, so they will never disappear from the
> set once in it.
> 
> Nowadays, it may be safe to put phi values in there.

Where?  in TMP_GEN?  That doesn't work.

> Honestly, the availability check in valid_in_sets worries me, because
> it shouldn't be necessary.
> Names should be prevented from being ANTIC past the point of their
> definition through subtraction of TMP_GEN.

Yes, removing the AVAIL_OUT check in clean works.

Richard.


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[dberlin at dberlin dot org]

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



------- Comment #25 from dberlin at gcc dot gnu dot org  2009-07-15 14:29 -------
Subject: Re:  [4.4/4.5 Regression] internal 
        compiler error: in compute_antic, at tree-ssa-pre.c:2501

On Wed, Jul 15, 2009 at 9:58 AM, rguenther at suse dot
de<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #24 from rguenther at suse dot de  2009-07-15 13:58 -------
> Subject: Re:  [4.4/4.5 Regression] internal
>  compiler error: in compute_antic, at tree-ssa-pre.c:2501
>
> On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
>
>> ------- Comment #23 from dberlin at gcc dot gnu dot org  2009-07-15 13:46 -------
>> Subject: Re:  [4.4/4.5 Regression] internal
>>         compiler error: in compute_antic, at tree-ssa-pre.c:2501
>>
>> a_1 shouldn't be in the maximal set. If it is, that's a bug.
>
> D.1251_5 = a_1->flag;
>
> so it's even in exp_gen.

I expect it got in exp_gen through add_to_exp_gen.
But the check there should have ensured it didn't get into the maximal set.


>  And because a_1 is in the maximal set
> b_2 has to.
>
> Well, as you asy - we'll see if it bootstraps ;)
>
>> The history here:
>>
>> We didn't use to have a check for domination in avail_out.
>> As a result, values only died if they were in TMP_GEN.
>> (This is what is *supposed* to happen. At some point we added a check
>> for availability to valid_in_sets and i can't remember why).
>> PHI values are not in TMP_GEN, so they will never disappear from the
>> set once in it.
>>
>> Nowadays, it may be safe to put phi values in there.
>
> Where?  in TMP_GEN?  That doesn't work.

Then how do we expect it to ever fall out of the set?
IE If a phi value enters ANTIC, what is going to prevent it from being
considered ANTIC all the way up the CFG?


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenther at suse dot de]

------- Comment #26 from rguenther at suse dot de  2009-07-15 15:00 -------
Subject: Re:  [4.4/4.5 Regression] internal
 compiler error: in compute_antic, at tree-ssa-pre.c:2501

On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:

> Subject: Re:  [4.4/4.5 Regression] internal 
>         compiler error: in compute_antic, at tree-ssa-pre.c:2501
> 
> On Wed, Jul 15, 2009 at 9:58 AM, rguenther at suse dot
> de<gcc-bugzilla@gcc.gnu.org> wrote:
> >
> >
> > ------- Comment #24 from rguenther at suse dot de ?2009-07-15 13:58 -------
> > Subject: Re: ?[4.4/4.5 Regression] internal
> > ?compiler error: in compute_antic, at tree-ssa-pre.c:2501
> >
> > On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
> >
> >> ------- Comment #23 from dberlin at gcc dot gnu dot org ?2009-07-15 13:46 -------
> >> Subject: Re: ?[4.4/4.5 Regression] internal
> >> ? ? ? ? compiler error: in compute_antic, at tree-ssa-pre.c:2501
> >>
> >> a_1 shouldn't be in the maximal set. If it is, that's a bug.
> >
> > D.1251_5 = a_1->flag;
> >
> > so it's even in exp_gen.
> 
> I expect it got in exp_gen through add_to_exp_gen.
> But the check there should have ensured it didn't get into the maximal set.

Indeed it's not in there.  The maximal set is w/o the patch

maximal[0] := { a_3(D) (0003), b_4(D) (0004), 
{component_ref<flag>,indirect_ref,a_1}@.MEM_13(D) (0005), 
{component_ref<pos>,indirect_ref,a_1}@.MEM_13(D) (0006), 
{component_ref<pos>,indirect_ref,b_2}@.MEM_13(D) (0007), 
{plus_expr,D.1254_10,D.1255_11} (0008) }

without them in the maximal-set we seem to get into non-monotonic
situations during ANTIC calculation because nobody cleans PHI_GEN, so
it will *add* bits. ... ?

The logic behind

"PHI nodes can't go in the maximal sets because they are not in
 TMP_GEN, so it is possible to get into non-monotonic situations
 during ANTIC calculation, because it will *add* bits."

sounds weird.  Isn't the maximal set only used initially, so it
will at most add bits once?

The patch btw bootstrapped and tested ok.

Richard.


-- 


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #27 from rguenth at gcc dot gnu dot org  2009-07-17 12:44 -------
Subject: Bug 40321

Author: rguenth
Date: Fri Jul 17 12:44:05 2009
New Revision: 149744

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149744
Log:
2009-07-17  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/40321
        * tree-ssa-pre.c (add_to_exp_gen): Also add names defined by
        PHI nodes to the maximal set.
        (make_values_for_phi): Add PHI arguments to the maximal set.
        (execute_pre): Dump PHI_GEN and the maximal set.

        * gcc.c-torture/compile/pr40321.c: New testcase.
        * g++.dg/torture/pr40321.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr40321.C
    trunk/gcc/testsuite/gcc.c-torture/compile/pr40321.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-pre.c


-- 


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

[Bug tree-optimization/40321] [4.4 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2009-07-17 12:44 -------
Fixed on the trunk sofar.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.4.0
      Known to work|                            |4.5.0
            Summary|[4.4/4.5 Regression]        |[4.4 Regression] internal
                   |internal compiler error: in |compiler error: in
                   |compute_antic, at tree-ssa- |compute_antic, at tree-ssa-
                   |pre.c:2501                  |pre.c:2501


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

[Bug tree-optimization/40321] [4.4 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #29 from rguenth at gcc dot gnu dot org  2009-07-22 14:45 -------
Subject: Bug 40321

Author: rguenth
Date: Wed Jul 22 14:45:21 2009
New Revision: 149935

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149935
Log:
2009-07-22  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/40321
        * tree-ssa-pre.c (add_to_exp_gen): Also add names defined by
        PHI nodes to the maximal set.
        (make_values_for_phi): Add PHI arguments to the maximal set.
        (execute_pre): Dump PHI_GEN and the maximal set.

        * gcc.c-torture/compile/pr40321.c: New testcase.
        * g++.dg/torture/pr40321.C: Likewise.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr40321.C
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40321.c
Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/gcc/tree-ssa-pre.c


-- 


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

[Bug tree-optimization/40321] [4.4 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

------- Comment #30 from rguenth at gcc dot gnu dot org  2009-07-22 14:47 -------
And for 4.4.2.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.4.0                       |4.4.0 4.4.1
         Resolution|                            |FIXED


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