------- Additional Comments From jakub at gcc dot gnu dot org 2005-02-15 15:53 ------- The bug is the infamous RTX_UNCHANGING_P, apparently still not dead. Well, now under the MEM_READONLY_P name.
The problem is that set_mem_attributes_minus_bitpos: 1532 tree base = get_base_address (t); 1533 if (base && DECL_P (base) 1534 && TREE_READONLY (base) 1535 && (TREE_STATIC (base) || DECL_EXTERNAL (base))) 1536 MEM_READONLY_P (ref) = 1; marks as MEM_READONLY_P even something that definitely is not readonly in the sense now documented in rtl.texi. main::b is TREE_READONLY, TREE_STATIC, but also e.g. TYPE_NEEDS_CONSTRUCTING. This variable is initialized to all zeros and then constructed (several fields to 0 which perhaps could be optimized out) and main::b._M_t._M_impl._M_header._M_left plus main::b._M_t._M_impl._M_header._M_right initially to &main::b._M_t. Then insert_unique is called 2 times to add fields to it. But because of the MEM_READONLY_P flag the RTL optimizers just assume that because it was initially set as main::b._M_t._M_impl._M_header._M_right = &main::b._M_t; then it will always have that value, so struct _Rb_tree_node_base * D.14743; D.14743 = b._M_t._M_impl._M_header._M_right; if (strcmp (*&((struct _Rb_tree_node<const char*> *) D.14743)->_M_value_field, D.14710) >= 0) goto <L39>; else goto <L40>; is mis-optimized into strcmp (main::b._M_t._M_impl._M_node_count, something); (_M_value_field is in the same position in _RB_tree_node's as in _M_node_count in _Rb_tree). Now, I wonder if we want a target hook here that will be called in addition to the above checks for MEM_READONLY_P setting and if so, what exact C++ classes with non-trivial constructors are guaranteed to not modify memory after relocation processing. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813