From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-334112-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30347 invoked by alias); 18 Oct 2010 17:13:15 -0000
Received: (qmail 30336 invoked by uid 22791); 18 Oct 2010 17:13:14 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,MISSING_MID
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; Mon, 18 Oct 2010 17:13:09 +0000
From: "bonzini at gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bonzini at gnu dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.5.2
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-45472-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45472-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: Mon, 18 Oct 2010 17:13: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-10/txt/msg01501.txt.bz2
Message-ID: <20101018171300.vsWqi75Tb0eUnI89Nyxp2VM4YdixsfvkusstnHs6c_s@z>

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

--- Comment #12 from Paolo Bonzini <bonzini at gnu dot org> 2010-10-18 17:12:59 UTC ---
It would be nice if for

    struct a {
        char a,b,c,d;
        volatile int e;
    };

    struct a v1, v2;
    ...
    v1 = v2;

the compiler emitted only _two_ memory accesses, one for a/b/c/d and one for e.
 I'm not sure a MEM_REF(&vv1) = MEM_REF(&vv2) with volatile arguments would
achieve this.

So, even though it's just an optimization, it would be better if the IR was
designed to allow it.  Would this be the case if the front-end emitted a
volatile MODIFY_EXPR?