From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6659 invoked by alias); 6 May 2005 02:37:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6563 invoked from network); 6 May 2005 02:37:35 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 6 May 2005 02:37:35 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j462bYb6014810 for ; Thu, 5 May 2005 19:37:34 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 5 May 2005 19:37:34 -0700 Received: from [17.219.197.241] ([17.219.197.241]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j462bWnL024380; Thu, 5 May 2005 19:37:32 -0700 (PDT) In-Reply-To: <9WGhhPLmw-B@khms.westfalen.de> References: <851D2CB0-93DF-4C49-A6A8-8895DB1A08F9@apple.com> <851D2CB0-93DF-4C49-A6A8-8895DB1A08F9@apple.com> <42778D99.7070904@codesourcery.com> <9WGhhPLmw-B@khms.westfalen.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6b9baa186e6aa332ea78dfbb1f4532fc@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, Dale Johannesen From: Dale Johannesen Subject: Re: volatile semantics Date: Fri, 06 May 2005 02:57:00 -0000 To: kaih@khms.westfalen.de (Kai Henningsen) X-SW-Source: 2005-05/txt/msg00280.txt.bz2 On May 5, 2005, at 5:23 AM, Kai Henningsen wrote: > nathan@codesourcery.com (Nathan Sidwell) wrote on 03.05.05 in > <42778D99.7070904@codesourcery.com>: >> Mike Stump wrote: >>> int avail; >>> int main() { >>> while (*(volatile int *)&avail == 0) >>> continue; >>> return 0; >>> } >>> >>> >>> Ok, so, the question is, should gcc produce code that infinitely >>> loops, >>> or should it be obligated to actually fetch from memory? Hint, 3.3 >>> fetched. >> >> I beleive the compiler is so licensed. [5.1.2.3/2] talks about >> accessing >> a volatile object. If the compiled can determine the actual object >> being accessed through a series of pointer and volatile cast >> conversions, >> then I see nothing in the std saying it must behave as-if the object >> were volatile when it is not. >> >> This, of course, might not be useful to users :) > > As a QOI issue, it would be nice if such a situation caused a warning > ("ignoring volatile cast ..." or something like that). > > It's rather dangerous to have the user believe that this worked as > intended when it didn't. If we aren't going to make this work as obviously intended, and the sentiment seems to be against it, then this is certainly a good idea.