public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
@ 2012-02-21 17:53 jamborm at gcc dot gnu.org
2012-02-21 17:58 ` [Bug middle-end/52329] " jamborm at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: jamborm at gcc dot gnu.org @ 2012-02-21 17:53 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
@ 2012-02-21 17:58 ` jamborm at gcc dot gnu.org
2012-02-21 18:34 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jamborm at gcc dot gnu.org @ 2012-02-21 17:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
2012-02-21 17:58 ` [Bug middle-end/52329] " jamborm at gcc dot gnu.org
@ 2012-02-21 18:34 ` jakub at gcc dot gnu.org
2012-02-21 18:56 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-02-21 18:34 UTC (permalink / raw)
To: gcc-bugs
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 &);
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
2012-02-21 17:58 ` [Bug middle-end/52329] " jamborm at gcc dot gnu.org
2012-02-21 18:34 ` jakub at gcc dot gnu.org
@ 2012-02-21 18:56 ` jakub at gcc dot gnu.org
2012-02-22 9:57 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-02-21 18:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
` (2 preceding siblings ...)
2012-02-21 18:56 ` jakub at gcc dot gnu.org
@ 2012-02-22 9:57 ` rguenth at gcc dot gnu.org
2012-02-22 9:58 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-02-22 9:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
` (3 preceding siblings ...)
2012-02-22 9:57 ` rguenth at gcc dot gnu.org
@ 2012-02-22 9:58 ` rguenth at gcc dot gnu.org
2012-02-22 10:04 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-02-22 9:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
` (4 preceding siblings ...)
2012-02-22 9:58 ` rguenth at gcc dot gnu.org
@ 2012-02-22 10:04 ` rguenth at gcc dot gnu.org
2012-02-22 11:22 ` rguenth at gcc dot gnu.org
2012-02-22 11:53 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-02-22 10:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
` (5 preceding siblings ...)
2012-02-22 10:04 ` rguenth at gcc dot gnu.org
@ 2012-02-22 11:22 ` rguenth at gcc dot gnu.org
2012-02-22 11:53 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-02-22 11:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
` (6 preceding siblings ...)
2012-02-22 11:22 ` rguenth at gcc dot gnu.org
@ 2012-02-22 11:53 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-02-22 11:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-22 11:23 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-21 17:53 [Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos jamborm at gcc dot gnu.org
2012-02-21 17:58 ` [Bug middle-end/52329] " jamborm at gcc dot gnu.org
2012-02-21 18:34 ` jakub at gcc dot gnu.org
2012-02-21 18:56 ` jakub at gcc dot gnu.org
2012-02-22 9:57 ` rguenth at gcc dot gnu.org
2012-02-22 9:58 ` rguenth at gcc dot gnu.org
2012-02-22 10:04 ` rguenth at gcc dot gnu.org
2012-02-22 11:22 ` rguenth at gcc dot gnu.org
2012-02-22 11:53 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).