From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9287 invoked by alias); 21 May 2005 20:48:48 -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 9265 invoked by uid 48); 21 May 2005 20:48:42 -0000 Date: Sat, 21 May 2005 20:48:00 -0000 Message-ID: <20050521204842.9264.qmail@sourceware.org> From: "schlie at comcast dot net" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050514140942.21568.rguenth@gcc.gnu.org> References: <20050514140942.21568.rguenth@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted X-Bugzilla-Reason: CC X-SW-Source: 2005-05/txt/msg03013.txt.bz2 List-Id: ------- Additional Comments From schlie at comcast dot net 2005-05-21 20:48 ------- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > This is undefined, see the full discussion on the gcc list: > > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html > > > > - out of curiosity, it's not clear that the discussion reached any > > conclusion which enables GCC to disreguard the type semantics > > as specifed by the program code. Where in the standard does it > > specify that a type qualifier may be disreguarded if convenient? > > See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html Thanks for the reference, I reviewed it and agree, but not for the reason stated. It has nothing to do with the declared type of the object, as a volatile qualified lvalue reference requires the object be accessed as a volatile, but may be fully optimized away iff it can be "deduced" that its omission would have no effect on the program's behavior. This was only reasonable to "deduce" because the objects address was not itself a literal address, or assigned to a volatile reference either directly or indirectly through a potential alias (as doing so would have extended the visibility of the object beyond the program itself, thereby requiring that the specified volatile access semantics be retained). In other words, in the following program variants, the specified volatile access could not have been optimized away: --- int avail; (volatile int *)0x0123 = &avail; // because it's value is now potentially // modifiable external to the program. int main() { while (*(volatile int *)&avail == 0) continue; return 0; } --- int *avail = (int *)0x0ABC; // as above, it's allocated location isn't private. int main() { while (*(volatile int *)avail == 0) continue; return 0; } --- Thanks, If this is what GCC formally does, it would be nice to see it documented? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568