From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1498 invoked by alias); 29 Sep 2003 22:42:14 -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 1461 invoked by uid 48); 29 Sep 2003 22:42:14 -0000 Date: Mon, 29 Sep 2003 23:07:00 -0000 Message-ID: <20030929224214.1460.qmail@sources.redhat.com> From: "janis187 at us dot ibm dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030926105501.12419.aph@gcc.gnu.org> References: <20030926105501.12419.aph@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug optimization/12419] [3.3/3.4 Regression] Performace regression: poor optimization of const memory X-Bugzilla-Reason: CC X-SW-Source: 2003-09/txt/msg02297.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12419 ------- Additional Comments From janis187 at us dot ibm dot com 2003-09-29 22:42 ------- The change reported in PR 12419 is somewhat erratic, although a regression hunt on the 3.3 branch identified this patch: --- gcc/gcc/ChangeLog --- 2003-04-07 Glen Nakamura PR opt/8634 * explow.c (maybe_set_unchanging): Don't flag non-static const aggregate type initializers with RTX_UNCHANGING_P. which includes the following new comment text: We cannot do this for non-static aggregates, because of the double writes that can be generated by store_constructor, depending on the contents of the initializer. Yes, this does eliminate a good fraction of the number of uses of RTX_UNCHANGING_P for a language like Ada. It also eliminates a good quantity of bugs. Let this be incentive to eliminate RTX_UNCHANGING_P entirely in favour of a more reliable solution, perhaps based on alias sets. The regression hunt on the 3.3-branch took place on i686-pc-linux-gnu using the submitter's test case compiled with -O2. A similar hunt on mainline identified the merge of the 3.4 improvements branch in December; very odd. Even more odd is that I get different results with recent mainline compilers depending on whether I use gcc or cc1 directly. Sounds like something is uninitialized.