------- 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
