This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined behavior or gcc is doing additional good job?


On Fri, Jan 3, 2014 at 4:24 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Jan 03, 2014 at 04:12:19PM +0800, Bin.Cheng wrote:
>> Hi, For below simple example:
>> #include <stdint.h>
>>
>> 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
Sorry for posting the premature question.  Since both __bss_start and
__data_start are declared as array, it seems there is no undefined
behavior, the check is between two pointers with same type actually,
right?  So the question remains, why GCC would clear the two lower
bits of " __data_start - __bss_start" then?  Am I some stupid mistake?

Thanks,
bin

> 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



-- 
Best Regards.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]