From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20371 invoked by alias); 3 Jan 2014 08:24:34 -0000 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 Received: (qmail 20361 invoked by uid 89); 3 Jan 2014 08:24:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Jan 2014 08:24:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s038OUWX002042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jan 2014 03:24:31 -0500 Received: from tucnak.zalov.cz (vpn1-5-96.ams2.redhat.com [10.36.5.96]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s038OTkL004055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 03:24:30 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id s038OStD028812; Fri, 3 Jan 2014 09:24:28 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id s038ORR0028811; Fri, 3 Jan 2014 09:24:27 +0100 Date: Fri, 03 Jan 2014 08:44:00 -0000 From: Jakub Jelinek To: "Bin.Cheng" Cc: "gcc@gcc.gnu.org" Subject: Re: Undefined behavior or gcc is doing additional good job? Message-ID: <20140103082427.GS892@tucnak.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00005.txt.bz2 On Fri, Jan 03, 2014 at 04:12:19PM +0800, Bin.Cheng wrote: > Hi, For below simple example: > #include > > extern uint32_t __bss_start[]; > extern uint32_t __data_start[]; > > void Reset_Handler(void) > { > /* Clear .bss section (initialize with zeros) */ > for (uint32_t* bss_ptr = __bss_start; bss_ptr != __data_start; ++bss_ptr) { > *bss_ptr = 0; > } > } I believe this is undefined behavior, so GCC can assume bss_ptr != __data_start is true always. You need something like memset (__bss_start, 0, (uintptr_t) __data_start - (uintptr_t) __bss_start); (note the cases to non-pointers), then it is just implementation defined behavior. Or do uint32_t data_ptr; asm ("" : "g" (data_ptr) : "0" (__data_start)); for (uint32_t* bss_ptr = __bss_start; bss_ptr != data_ptr; ++bss_ptr) { *bss_ptr = 0; } and thus hide from the compiler the fact that __data_start is in a different object. Jakub