From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19603 invoked by alias); 21 Sep 2011 07:07:01 -0000 Received: (qmail 19577 invoked by uid 22791); 21 Sep 2011 07:06:56 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Sep 2011 07:06:33 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6Gt6-0000AA-8I for gcc@gcc.gnu.org; Wed, 21 Sep 2011 09:06:32 +0200 Received: from 79.161.10.130 ([79.161.10.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 09:06:32 +0200 Received: from david by 79.161.10.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 09:06:32 +0200 To: gcc@gcc.gnu.org From: David Brown Subject: Re: Volatile qualification on pointer and data Date: Wed, 21 Sep 2011 07:07:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00203.txt.bz2 On 20/09/2011 18:35, Ian Lance Taylor wrote: > "Paulo J. Matos" writes: > >> The following code: >> static const unsigned int foo = 1; >> unsigned int test( void ) >> { >> const volatile unsigned int *bar =&foo; >> return ( *bar ); >> } >> >> in GCC45 works as expected: >> $test: >> ld AL,#foo ;; AL is return register >> bra 0,X ;; end function >> >> in GCC46: >> $test: >> ld AL,0 >> bra 0,X >> >> This is worrying because qualifying the data as volatile should be >> enough to prevent these sort of optimizations. It did until GCC46. > > I agree that this looks like a bug. Please file a bug report marked as > a regression. > > Ian > Are you sure about that? In the declaration of "bar", the "const" part is just a promise to the compiler that the code won't try to change the data pointed to by bar. But when "foo" is defined as "const", that tells the compiler that foo cannot change, and being "static" and non-volatile, the compiler then knows everything about foo and can eliminate it in the code. Asking to read it by a volatile read does not change the nature of "foo" - the compiler can still implement it as a compile-time constant. So the compiler does it's best to generate code for a volatile read of an immediate constant. David