[Bug target/48031] New: [4,4, 4.5 regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[Bug target/48031] New: [4,4, 4.5 regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

           Summary: [4,4, 4.5 regression] gcc.c-torture/compile/pr42956.c
                    ICEs gcc on m68k-linux, ivopts related?
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mikpe@it.uu.se


The pr42956.c test case ICEs gcc 4.5 and 4.4 on m68k-linux:

> gcc/xgcc -Bgcc -O1 -S /.../gcc/testsuite/gcc.c-torture/compile/pr42956.c
/.../gcc/testsuite/gcc.c-torture/compile/pr42956.c: In function 'Split':
/.../gcc/testsuite/gcc.c-torture/compile/pr42956.c:10:6: error: expected an
SSA_NAME object
/.../gcc/testsuite/gcc.c-torture/compile/pr42956.c:10:6: error: in statement
D.2041_132 = D.1987 /[ex] 2;
/.../gcc/testsuite/gcc.c-torture/compile/pr42956.c:10:6: internal compiler
error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This is with a cross to m68k-linux and --enable-checking=yes, with
--enable-checking=release the compiler segfaults instead.

Compiling with -O1 -fno-ivopts or -O0 eliminates the ICE.

This bug occurs with gcc-4.4.5 and gcc-4.5.2.  It does not occur with
gcc-4.3.5.  For gcc-4.6 it stopped occurring after the big MEM_REF update in
r161655.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization
   Target Milestone|---                         |4.4.6
            Summary|[4.4, 4.5 regression]       |[4.4/4.5 Regression]
                   |gcc.c-torture/compile/pr429 |gcc.c-torture/compile/pr429
                   |56.c ICEs gcc on            |56.c ICEs gcc on
                   |m68k-linux, ivopts related? |m68k-linux, ivopts related?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.4.0, 4.4.1, 4.4.2
      Known to fail|                            |4.4.3

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-08 14:22:46 UTC ---
The bug was introduced on 4.4 branch between 4.4.2 (works) and 4.4.3 (broken). 
I'm starting a bisection.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-08 21:40:03 UTC ---
The bug in 4.4 branch began with r154046, Jakub's fix for PR40946 which
backported r151559 (PR41317 fix) from 4.5.  Checking 4.5 branch confirmed that
r151558 works while r151559 has the bug.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-09 09:21:46 UTC ---
On Tue, 8 Mar 2011, mikpe at it dot uu.se wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> Mikael Pettersson <mikpe at it dot uu.se> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-08 21:40:03 UTC ---
> The bug in 4.4 branch began with r154046, Jakub's fix for PR40946 which
> backported r151559 (PR41317 fix) from 4.5.  Checking 4.5 branch confirmed that
> r151558 works while r151559 has the bug.

Which means that change triggers a latent bug.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-09 23:36:44 UTC ---
(In reply to comment #3)
> On Tue, 8 Mar 2011, mikpe at it dot uu.se wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> > 
> > Mikael Pettersson <mikpe at it dot uu.se> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |rguenth at gcc dot gnu.org
> > 
> > --- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-08 21:40:03 UTC ---
> > The bug in 4.4 branch began with r154046, Jakub's fix for PR40946 which
> > backported r151559 (PR41317 fix) from 4.5.  Checking 4.5 branch confirmed that
> > r151558 works while r151559 has the bug.
> 
> Which means that change triggers a latent bug.

I backported r151559 to successively older trunk revisions, and found that
r139061 is the revision that breaks when combined with r151559.

r139061 is Richard's 'Make CCP "complete"' patch, see
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00877.html

I'll investigate further tomorrow.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-10 09:22:04 UTC ---
If I revert this part of r139061 then things work again:

    * gimplify.c (gimplify_conversion): Use maybe_fold_offset_to_address.

--- gcc/gimplify.c      (revision 139060)
+++ gcc/gimplify.c      (revision 139061)
@@ -1842,17 +1842,13 @@ gimplify_conversion (tree *expr_p)
   /* Attempt to avoid NOP_EXPR by producing reference to a subtype.
      For example this fold (subclass *)&A into &A->subclass avoiding
      a need for statement.  */
-  if (TREE_CODE (*expr_p) == NOP_EXPR
+  if (CONVERT_EXPR_P (*expr_p)
       && POINTER_TYPE_P (TREE_TYPE (*expr_p))
       && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (*expr_p, 0)))
-      && (tem = maybe_fold_offset_to_reference
+      && (tem = maybe_fold_offset_to_address
                  (TREE_OPERAND (*expr_p, 0),
-                  integer_zero_node, TREE_TYPE (TREE_TYPE (*expr_p)))))
-    {
-      tree ptr_type = build_pointer_type (TREE_TYPE (tem));
-      if (useless_type_conversion_p (TREE_TYPE (*expr_p), ptr_type))
-        *expr_p = build_fold_addr_expr_with_type (tem, ptr_type);
-    }
+                  integer_zero_node, TREE_TYPE (*expr_p))) != NULL_TREE)
+    *expr_p = tem;

   /* If we still have a conversion at the toplevel,
      then canonicalize some constructs.  */

The first condition change is Ok, it's the change to call m_f_o_t_address
instead of m_f_o_t_reference and the then-clause change that matter.

Reverting this from trunk @ r139061 + r151559 backport, or trunk @ r151559,
eliminates the ICE.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-10 09:33:49 UTC ---
On Thu, 10 Mar 2011, mikpe at it dot uu.se wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #5 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-10 09:22:04 UTC ---
> If I revert this part of r139061 then things work again:
> 
>     * gimplify.c (gimplify_conversion): Use maybe_fold_offset_to_address.
> 
> --- gcc/gimplify.c      (revision 139060)
> +++ gcc/gimplify.c      (revision 139061)
> @@ -1842,17 +1842,13 @@ gimplify_conversion (tree *expr_p)
>    /* Attempt to avoid NOP_EXPR by producing reference to a subtype.
>       For example this fold (subclass *)&A into &A->subclass avoiding
>       a need for statement.  */
> -  if (TREE_CODE (*expr_p) == NOP_EXPR
> +  if (CONVERT_EXPR_P (*expr_p)
>        && POINTER_TYPE_P (TREE_TYPE (*expr_p))
>        && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (*expr_p, 0)))
> -      && (tem = maybe_fold_offset_to_reference
> +      && (tem = maybe_fold_offset_to_address
>                   (TREE_OPERAND (*expr_p, 0),
> -                  integer_zero_node, TREE_TYPE (TREE_TYPE (*expr_p)))))
> -    {
> -      tree ptr_type = build_pointer_type (TREE_TYPE (tem));
> -      if (useless_type_conversion_p (TREE_TYPE (*expr_p), ptr_type))
> -        *expr_p = build_fold_addr_expr_with_type (tem, ptr_type);
> -    }
> +                  integer_zero_node, TREE_TYPE (*expr_p))) != NULL_TREE)
> +    *expr_p = tem;
> 
>    /* If we still have a conversion at the toplevel,
>       then canonicalize some constructs.  */
> 
> The first condition change is Ok, it's the change to call m_f_o_t_address
> instead of m_f_o_t_reference and the then-clause change that matter.
> 
> Reverting this from trunk @ r139061 + r151559 backport, or trunk @ r151559,
> eliminates the ICE.

I think this is all just the right circumstances for triggering the bug.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.03.10 11:02:33
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-10 11:02:33 UTC ---
First of all, confirmed with a cross.

The issue seems to be with variable-length arrays:

  D.2079_96 = D.2025 /[ex] 2;
  D.2080_21 = &(*D.2050_128)[0]{lb: 0 sz: D.2079_96 * 2}.err;

What happens is that we have an induction variable base of the form
(unsigned int) &((struct Result *) D.2050_128)->err and end up folding
the conversion to an array reference during gimplifying it here

  /* *(foo *)fooarrptr => (*fooarrptr)[0] */
  if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
      && type == TREE_TYPE (TREE_TYPE (subtype)))
    {
      tree type_domain;
      tree min_val = size_zero_node;
      sub = build_fold_indirect_ref_loc (loc, sub);
      type_domain = TYPE_DOMAIN (TREE_TYPE (sub));
      if (type_domain && TYPE_MIN_VALUE (type_domain))
        min_val = TYPE_MIN_VALUE (type_domain);
      return build4_loc (loc, ARRAY_REF, type, sub, min_val, NULL_TREE,
                         NULL_TREE);
    }

and then add a lower bound and step element in gimplify_compound_lval:

          if (!TREE_OPERAND (t, 3))
            {
              tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 0)));
              tree elmt_size = unshare_expr (array_ref_element_size (t));
              tree factor = size_int (TYPE_ALIGN_UNIT (elmt_type));

              /* Divide the element size by the alignment of the element
                 type (above).  */
              elmt_size = size_binop_loc (loc, EXACT_DIV_EXPR, elmt_size,
factor);

              if (!is_gimple_min_invariant (elmt_size))
                {
                  TREE_OPERAND (t, 3) = elmt_size;
                  tret = gimplify_expr (&TREE_OPERAND (t, 3), pre_p,
                                        post_p, is_gimple_reg,
                                        fb_rvalue);
                  ret = MIN (ret, tret);
                }
            }


A fix would be for example avoiding the folding for variable-sized element
types.  Another one would be to avoid putting in a operand 3 into the
array-ref when the index is equal to the lower bound (but I'm not sure
if that works, if the index is zero would probably work, but then a
variant of the code might still ICE the same way).

It's mixing VLA unaware foldings into the mids of GIMPLE which is the
root of the issue though.  The issue is latent on trunk.

Patch for the first (and safe) idea:

Index: gcc/fold-const.c
===================================================================
--- gcc/fold-const.c    (revision 170818)
+++ gcc/fold-const.c    (working copy)
@@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
        }
       /* *(foo *)&fooarray => fooarray[0] */
       else if (TREE_CODE (optype) == ARRAY_TYPE
-              && type == TREE_TYPE (optype))
+              && type == TREE_TYPE (optype)
+              && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
        {
          tree type_domain = TYPE_DOMAIN (optype);
          tree min_val = size_zero_node;
@@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre

   /* *(foo *)fooarrptr => (*fooarrptr)[0] */
   if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
-      && type == TREE_TYPE (TREE_TYPE (subtype)))
+      && type == TREE_TYPE (TREE_TYPE (subtype))
+      && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
     {
       tree type_domain;
       tree min_val = size_zero_node;

Eric, can you see any issues with that and Ada?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 12:34:57 UTC ---
> It's mixing VLA unaware foldings into the mids of GIMPLE which is the
> root of the issue though.  The issue is latent on trunk.
> 
> Patch for the first (and safe) idea:
> 
> Index: gcc/fold-const.c
> ===================================================================
> --- gcc/fold-const.c    (revision 170818)
> +++ gcc/fold-const.c    (working copy)
> @@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
>         }
>        /* *(foo *)&fooarray => fooarray[0] */
>        else if (TREE_CODE (optype) == ARRAY_TYPE
> -              && type == TREE_TYPE (optype))
> +              && type == TREE_TYPE (optype)
> +              && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
>         {
>           tree type_domain = TYPE_DOMAIN (optype);
>           tree min_val = size_zero_node;
> @@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
> 
>    /* *(foo *)fooarrptr => (*fooarrptr)[0] */
>    if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
> -      && type == TREE_TYPE (TREE_TYPE (subtype)))
> +      && type == TREE_TYPE (TREE_TYPE (subtype))
> +      && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
>      {
>        tree type_domain;
>        tree min_val = size_zero_node;
> 
> Eric, can you see any issues with that and Ada?

If this is limited to the in_gimple_form case, probably none.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-10 12:36:33 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 12:34:57 UTC ---
> > It's mixing VLA unaware foldings into the mids of GIMPLE which is the
> > root of the issue though.  The issue is latent on trunk.
> > 
> > Patch for the first (and safe) idea:
> > 
> > Index: gcc/fold-const.c
> > ===================================================================
> > --- gcc/fold-const.c    (revision 170818)
> > +++ gcc/fold-const.c    (working copy)
> > @@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
> >         }
> >        /* *(foo *)&fooarray => fooarray[0] */
> >        else if (TREE_CODE (optype) == ARRAY_TYPE
> > -              && type == TREE_TYPE (optype))
> > +              && type == TREE_TYPE (optype)
> > +              && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
> >         {
> >           tree type_domain = TYPE_DOMAIN (optype);
> >           tree min_val = size_zero_node;
> > @@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
> > 
> >    /* *(foo *)fooarrptr => (*fooarrptr)[0] */
> >    if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
> > -      && type == TREE_TYPE (TREE_TYPE (subtype)))
> > +      && type == TREE_TYPE (TREE_TYPE (subtype))
> > +      && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
> >      {
> >        tree type_domain;
> >        tree min_val = size_zero_node;
> > 
> > Eric, can you see any issues with that and Ada?
> 
> If this is limited to the in_gimple_form case, probably none.

No it isn't.  But given that fold at this place doesn't even
fill in the array-ref element-size slot but provides NULL_TREE
it is probably a fix for the better anyway?

Richard.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 12:46:33 UTC ---
> No it isn't.  But given that fold at this place doesn't even
> fill in the array-ref element-size slot but provides NULL_TREE
> it is probably a fix for the better anyway?

Why not explicitly test in_gimple_form like in other places in the folder?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-10 12:57:59 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 12:46:33 UTC ---
> > No it isn't.  But given that fold at this place doesn't even
> > fill in the array-ref element-size slot but provides NULL_TREE
> > it is probably a fix for the better anyway?
> 
> Why not explicitly test in_gimple_form like in other places in the folder?

That would work, too.  You see no problem with a NULL operand 3
of array-refs?  If you create an array with a variable lower bound,
take its address, convert it to pointer to element type and
dereference that, would it expand ok if it does not have the
element size set properly?  At least get_inner_reference seems to
unconditionally multiply with array_ref_element_size () * index,
and array_ref_element_size () does not work for variable-size types
if the array-ref doesn't have the gimplified value.

You can probably come up with an Ada testcase that gets miscompiled?
(C arrays always have a lower bound of zero, thus the index
will be zero thus the multiplication ensures that the garbage
returned by array_ref_element_size is thrown away).

Richard.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 13:04:17 UTC ---
> That would work, too.  You see no problem with a NULL operand 3
> of array-refs?  If you create an array with a variable lower bound,
> take its address, convert it to pointer to element type and
> dereference that, would it expand ok if it does not have the
> element size set properly?  At least get_inner_reference seems to
> unconditionally multiply with array_ref_element_size () * index,
> and array_ref_element_size () does not work for variable-size types
> if the array-ref doesn't have the gimplified value.

Isn't gimplification supposed to populate this operand #3?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-10 13:07:16 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 13:04:17 UTC ---
> > That would work, too.  You see no problem with a NULL operand 3
> > of array-refs?  If you create an array with a variable lower bound,
> > take its address, convert it to pointer to element type and
> > dereference that, would it expand ok if it does not have the
> > element size set properly?  At least get_inner_reference seems to
> > unconditionally multiply with array_ref_element_size () * index,
> > and array_ref_element_size () does not work for variable-size types
> > if the array-ref doesn't have the gimplified value.
> 
> Isn't gimplification supposed to populate this operand #3?

Ugh, yeah it does - but, do we really rely on this?  Probably yes ...
so setting operand #2 in the folder is not necessary either.

Ok, I'll go with the in_gimple_form check.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-10 13:10:23 UTC ---
Created attachment 23614
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23614
patch

testing appreciated

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-10 14:03:22 UTC ---
(In reply to comment #14)
> Created attachment 23614 [details]
> patch
> 
> testing appreciated

Thanks, fixes the ICE in 4.5 and 4.4 crosses to m68k-linux.  I'm starting
native 4.6/4.5/4.4 bootstraps and test suite runs today, expect results in 4-5
days.

(I'm running them in parallel on three machines.  A languages=c,c++
checking=release bootstrap+regtest does unfortunately take that long.)

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #16 from Mikael Pettersson <mikpe at it dot uu.se> 2011-03-15 08:44:29 UTC ---
(In reply to comment #14)
> Created attachment 23614 [details]
> patch
> 
> testing appreciated

Applied to gcc 4.6/4.5/4.4 then bootstrapped and regression tested on
m68k-linux with --enable-languages=c,c++.  No bootstrap failures or test suite
regressions.  Fixed pr42956.c FAILs with 4.5/4.4.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-15 09:49:39 UTC ---
Author: rguenth
Date: Tue Mar 15 09:49:33 2011
New Revision: 170983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170983
Log:
2011-03-15  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48031
    * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized
    or variable-indexed array accesses when in gimple form.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-28 10:14:39 UTC ---
Author: rguenth
Date: Mon Mar 28 10:14:34 2011
New Revision: 171595

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171595
Log:
2011-03-28  Richard Guenther  <rguenther@suse.de>

    Backport from mainline
    2011-03-24  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48269
    * tree-object-size.c (addr_object_size): Do not double-account
    for MEM_REF offsets.

    * gcc.dg/builtin-object-size-10.c: New testcase.

    2011-03-22  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/48228
    * tree-vrp.c (vrp_visit_phi_node): Do not stop propagating
    for single-arg PHIs.

    * gcc.dg/Wstrict-overflow-23.c: New testcase.

    2011-03-17  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48134
    * tree-ssa.c (insert_debug_temp_for_var_def): If we propagated
    a value make sure to fold the statement.

    * gcc.dg/pr48134.c: New testcase.

    2011-03-15  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48031
    * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized
    or variable-indexed array accesses when in gimple form.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-23.c
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-10.c
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48134.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/fold-const.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-object-size.c
    branches/gcc-4_6-branch/gcc/tree-ssa.c
    branches/gcc-4_6-branch/gcc/tree-vrp.c

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.6                       |4.4.7

[Bug tree-optimization/48031] [4.4 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
      Known to work|                            |4.5.3
         AssignedTo|rguenth at gcc dot gnu.org  |unassigned at gcc dot
                   |                            |gnu.org
            Summary|[4.4/4.5 Regression]        |[4.4 Regression]
                   |gcc.c-torture/compile/pr429 |gcc.c-torture/compile/pr429
                   |56.c ICEs gcc on            |56.c ICEs gcc on
                   |m68k-linux, ivopts related? |m68k-linux, ivopts related?

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-18 14:05:28 UTC ---
Fixed for the reported branch as well.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-18 14:02:27 UTC ---
Author: rguenth
Date: Mon Apr 18 14:02:22 2011
New Revision: 172647

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172647
Log:
2011-04-18  Richard Guenther  <rguenther@suse.de>

    Backported from 4.6 branch 
    2011-03-11  Jakub Jelinek  <jakub@redhat.com>

    PR c++/48035
    * init.c (build_zero_init_1): Extracted from build_zero_init.
    Add FIELD_SIZE argument, if non-NULL and field bit_position
    as not smaller than that, don't add that field's initializer.
    Pass DECL_SIZE as last argument to build_zero_init_1
    for DECL_FIELD_IS_BASE fields.
    (build_zero_init): Use build_zero_init_1.

    * g++.dg/inherit/virtual8.C: New test.

    2011-03-05  Zdenek Dvorak  <ook@ucw.cz>

    PR rtl-optimization/47899
    * cfgloopmanip.c (fix_bb_placements): Fix first argument
    to flow_loop_nested_p when moving the loop upward.

    * gcc.dg/pr47899.c: New test.

    2011-03-15  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48031
    * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized
    or variable-indexed array accesses when in gimple form.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/cfgloopmanip.c
    branches/gcc-4_5-branch/gcc/cp/ChangeLog
    branches/gcc-4_5-branch/gcc/cp/init.c
    branches/gcc-4_5-branch/gcc/fold-const.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/48031] [4.4 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-18 14:37:18 UTC ---
Author: rguenth
Date: Mon Apr 18 14:37:08 2011
New Revision: 172652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172652
Log:
2011-04-18  Richard Guenther  <rguenther@suse.de>

    Backported from 4.6 branch 
    2011-03-11  Jakub Jelinek  <jakub@redhat.com>

    PR c++/48035
    * init.c (build_zero_init_1): Extracted from build_zero_init.
    Add FIELD_SIZE argument, if non-NULL and field bit_position
    as not smaller than that, don't add that field's initializer.
    Pass DECL_SIZE as last argument to build_zero_init_1
    for DECL_FIELD_IS_BASE fields.
    (build_zero_init): Use build_zero_init_1.

    * g++.dg/inherit/virtual8.C: New test.

    2011-03-05  Zdenek Dvorak  <ook@ucw.cz>

    PR rtl-optimization/47899
    * cfgloopmanip.c (fix_bb_placements): Fix first argument
    to flow_loop_nested_p when moving the loop upward.

    * gcc.dg/pr47899.c: New test.

    2011-03-15  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48031
    * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized
    or variable-indexed array accesses when in gimple form.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/g++.dg/inherit/virtual8.C
    branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr47899.c

[Bug tree-optimization/48031] [4.4 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |FIXED
   Target Milestone|4.4.7                       |4.5.3

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 13:28:09 UTC ---
Fixed in 4.5+, 4.4 is no longer supported.