[Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[jamborm at gcc dot gnu.org]

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

             Bug #: 52329
           Summary: Invalid MEM_REF encountered in
                    set_mem_attributes_minus_bitpos
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jamborm@gcc.gnu.org
                CC: jakub@gcc.gnu.org
              Host: x86_64-suse-linux
            Target: x86_64-suse-linux
             Build: x86_64-suse-linux


Created attachment 26716
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26716
Preprocessed source

Bootstrapping revision 184388 with the following patch

Index: gcc/emit-rtl.c
===================================================================
--- gcc/emit-rtl.c      (revision 184388)
+++ gcc/emit-rtl.c      (working copy)
@@ -1681,6 +1681,7 @@ set_mem_attributes_minus_bitpos (rtx ref
       MEM_NOTRAP_P (ref) = !tree_could_trap_p (t);

       base = get_base_address (t);
+      gcc_assert (base);
       if (base && DECL_P (base)
          && TREE_READONLY (base)
          && (TREE_STATIC (base) || DECL_EXTERNAL (base))

causes an ICE when compiling libstdc++-v3/src/c++98/complex_io.cc
because get_base_address stumbles upon encountering an invalid
MEM_REF

MEM[(struct basic_stringbuf *)&__s._M_stringbuf]._M_string

and returns NULL.

This expression is passed to it by expand_debug_expr via
set_mem_attributes.

Attached is the preprocessed testcase, invocation flags
are -g -O2 -S

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> 2012-02-21 17:51:10 UTC ---
Created attachment 26717
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26717
Delta reduced testcase

This as far as I managed to reduce the testcase with multidelta.

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-21 18:24:37 UTC ---
Slightly more reduced testcase for -O2 -g:
template <typename>
class A;
template <class>
struct B;
template <typename T, typename = B <T>, typename = A <T> >
class C;
template <typename _Tp>
class A {};
template <typename T, typename, typename U>
struct D
{
  struct E
  {
    T *e1 () {}
    void e2 (U a) { e3 (a); }
    void e3 (U) throw ();
  };
  struct F { F (T *, U) {} };
  F f;
  E *d1 () {}
  static E & d2 () {}
  D () : f (d2 ().e1 (), U ())
  {
    d1 ()->e2 (this->d3 ());
  }
  U d3 () {}
};
template <typename, typename>
struct G
{
  virtual ~G () {}
};
template <typename T, typename U>
struct H
{
  void h1 (G <T, U> *);
};
template <typename T, typename U>
struct I : H <T, U>
{
  I () { this->h1 (0); }
};
template <typename T, typename U, typename V>
struct J : G <T, U>
{
  D <T, U, V> j;
};
template <typename T, typename U, typename V>
struct C : I <T, U>
{
  J <T, U, V> c;
};
struct K;
template <typename T, class U>
I <T, U>
& operator <<(I <T, U> &, const K &)
{
  C <U> s;
}
template I <wchar_t, B <wchar_t> >
& operator <<(I <wchar_t, B <wchar_t> >&, const K &);

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-21 18:41:01 UTC ---
Richard, so what exactly is not kosher?
We have:
# DEBUG D#7 => &s.c.D.2422
...
MEM[(struct J *)&s].D.2422._vptr.G = &MEM[(void *)&_ZTV1JI1BIwES0_IS1_E1AIS1_EE
+ 16B];
in the optimized dump, &s.c.D.2422 is ADDR_EXPR of COMPONENT_REF of MEM_REF,
the first operand in the real stmt is COMPONENT_REF of COMPONENT_REF of
MEM_REF.

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-22
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 09:47:35 UTC ---
# DEBUG D#7 => &s.c.D.2422

seems to be

 <addr_expr 0x7ffff5821e60
    type <pointer_type 0x7ffff5bb5930
...
    arg 0 <component_ref 0x7ffff5c06ce8 type <record_type 0x7ffff5bb5888 G>

        arg 0 <mem_ref 0x7ffff5c0cb40 type <record_type 0x7ffff5bbd0a8 J>

            arg 0 <addr_expr 0x7ffff5821618 type <pointer_type 0x7ffff5bc3d20>

                arg 0 <component_ref 0x7ffff5c06ea8 type <record_type
0x7ffff5bbd0a8 J>
                    arg 0 <var_decl 0x7ffff5a298c0 s> arg 1 <field_decl
0x7ffff5baeda8 c>>

thus &(MEM_REF (&s.c).D.2422).  What is not ok is that the first operand
of the MEM_REF is not is_gimple_mem_ref_addr ().

Valid would be &(MEM_REF (&s + 0).D.2422) for example, which fold would
canonicalize the MEM_REF sub-tree to.

Unfortunately we do not verify anything in gimple_debug stmts :(

[sorry for the un-obfuscation during pretty-printing ;)]

It seems that this is introduced by propagating into debug stmts as we go
from

t.ii.058t.copyrename2:  # DEBUG D#4 => &D.2734_8->D.2422
t.ii.058t.copyrename2:  # DEBUG this => D#4

to

t.ii.060t.ccp2:  # DEBUG D#4 => &s.c.D.2422
t.ii.060t.ccp2:  # DEBUG this => D#4

and the issue there seems to be that GIMPLE_DEBUG handling in fold_stmt
does not look at ADDR_EXPRs but only REFERENCE_CLASS_P stuff.  See
the ADDR_EXPR handling in fold_gimple_assign.

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 09:57:22 UTC ---
I'm not sure we care about preserving pointer types in debug stmts, nor if
the mem-ref stripping is needed (well, build_fold_addr_expr does that, too).

Index: gcc/gimple-fold.c
===================================================================
--- gcc/gimple-fold.c   (revision 184460)
+++ gcc/gimple-fold.c   (working copy)
@@ -1250,6 +1250,18 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
                  changed = true;
                }
            }
+         else if (val
+                  && TREE_CODE (val) == ADDR_EXPR)
+           {
+             tree ref = TREE_OPERAND (val, 0);
+             tree tem = maybe_fold_reference (ref, false);
+             if (tem)
+               {
+                 tem = build_fold_addr_expr_with_type (tem, TREE_TYPE (val));
+                 gimple_debug_bind_set_value (stmt, tem);
+                 changed = true;
+               }
+           }
        }
       break;

fixes it for me.

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 09:58:31 UTC ---
Mine.

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 11:21:53 UTC ---
Author: rguenth
Date: Wed Feb 22 11:21:48 2012
New Revision: 184466

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

    PR middle-end/52329
    * gimple-fold.c (fold_stmt_1): Also canonicalize ADDR_EXPRs
    for GIMPLE_DEBUG stmts.

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

[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 11:22:06 UTC ---
Fixed on trunk.