From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14771 invoked by alias); 15 Feb 2005 15:54:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 14353 invoked by uid 48); 15 Feb 2005 15:53:49 -0000 Date: Tue, 15 Feb 2005 21:15:00 -0000 Message-ID: <20050215155349.14352.qmail@sourceware.org> From: "jakub at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050207230934.19813.ctsa@u.washington.edu> References: <20050207230934.19813.ctsa@u.washington.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug regression/19813] [4.0 Regression] wrong code with -finline-limit X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg01616.txt.bz2 List-Id: ------- 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 *) D.14743)->_M_value_field, D.14710) >= 0) goto ; else goto ; 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