From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-383775-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1599 invoked by alias); 16 Feb 2012 19:50:38 -0000
Received: (qmail 1590 invoked by uid 22791); 16 Feb 2012 19:50:37 -0000
X-SWARE-Spam-Status: No, hits=-2.9 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; Thu, 16 Feb 2012 19:49:50 +0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
Date: Thu, 16 Feb 2012 19:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason 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.5.4
X-Bugzilla-Changed-Fields:
Message-ID: <bug-45472-4-dcUCEGWmXQ@http.gcc.gnu.org/bugzilla/>
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
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: 2012-02/txt/msg01709.txt.bz2

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

--- Comment #19 from Jason Merrill <jason at gcc dot gnu.org> 2012-02-16 19:41:29 UTC ---
It seems to me that volatile reads/writes should get their own gimple
statements, not be part of a larger block move.  So instead of

  vv1 = vv2;

we should have

  vv1.a ={v} vv2.a;
  vv1.b ={v} vv2.b;

I agree with Paolo's comment in #12 that we want to copy the non-volatile parts
as a block when possible.  It seems like breaking a simple struct assignment
into these separate statements would be best done in the gimplifier so that
front ends don't need to get this right independently.

Out of curiousity, what is the use case for a non-volatile struct object with
volatile members?