[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit

jakub at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Tue Feb 15 21:15:00 GMT 2005

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


More information about the Gcc-bugs mailing list