From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18020 invoked by alias); 20 Jun 2011 14:04:58 -0000 Received: (qmail 18009 invoked by uid 22791); 20 Jun 2011 14:04:58 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 14:04:43 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id B51075FC9F; Mon, 20 Jun 2011 16:04:41 +0200 (CEST) Date: Mon, 20 Jun 2011 14:20:00 -0000 From: Michael Matz To: Mike Stump Cc: Eric Botcazou , Duncan Sands , gcc-patches@gcc.gnu.org Subject: Re: [Ada] Fix bugs with volatile and components of aggregate types In-Reply-To: Message-ID: References: <201106181255.09679.ebotcazou@adacore.com> <4DFDF18E.8090201@free.fr> <201106200124.49880.ebotcazou@adacore.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01472.txt.bz2 Hi, On Sun, 19 Jun 2011, Mike Stump wrote: > >> if T is a non-volatile composite type with volatile components, and O > >> is an object of type T, are the optimizers allowed to remove the > >> assignment "O := O"? > > > > Good question, that I'm not really qualified to answer. Any language > > lawyer? > > I'd like to think that the optimizers are not allowed to remove the > assignment (unless they synthesize of up the assignment of all volatile > fields). For unions, head explodes. I think for unions, it can. I > could check the standard to ensure I have it right, but, well, that's > annoying. :-) This answer is for the answer for C and C++, but, the > middle end, _could_ decide to differ, if it had a compelling reason to. > I don't know of any reason. Now, before someone tries to optimize > structures, please be very careful. Unions, transparent unions, > frontend synthed structures with multiple offsets at the same location > and the like come to mind. The middle end really can't decide. See also PR45472, from comment #7: ----------------------------------------------- This all points to a deeper problem IMO, one we need to decide how to solve before tackling the details of this bug, namely: how are non-volatile objects containing volatile subobjects handled? I don't know if the language standard says anything about this. We have several possibilities: 1) make all objects containing volatile subobjects volatile itself 2) make instructions touching such objects volatile 3) make instructions touching the volatile components volatile The first has the problem that volatile objects with aggregate type implicitely contain only volatile subobjects, that is for such object: struct {int a; volatile int b;} half_volatile; with solution (1) this would be equivalent to volatile struct {int a; volatile int b;} half_volatile; and hence halt_volatile.a would be volatile too, probably unlike the author intended. The other two solutions are more work, especially because the half-volatility wouldn't be reflected in the objects type. ----------------------------------------------- Downwards we decided that it's really the languages business to define half-volatility, so it either needs to or doesn't need to emit volatile mem_refs according to its standard. Ciao, Michael.