From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-335879-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2848 invoked by alias); 5 Nov 2010 10:03:30 -0000
Received: (qmail 2839 invoked by uid 22791); 5 Nov 2010 10:03:29 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Nov 2010 10:03:26 +0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.0
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-45670-4-fZqtLgKoGy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-45670-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45670-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Fri, 05 Nov 2010 10:03:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2010-11/txt/msg00612.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45670

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-05 10:03:15 UTC ---
Well, it is actually very much related to that reversion.  While it didn't
regress in between 161907 and 162617, it regressed from the MEM_REF merge till
161906 and from 162618 onwards.
The problem is that due to the MEM load combiner isn't able to fix this up, so
if we don't get it right during expansion, we are out of luck.  Looking at it
now...