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: const volatile behaviour change in GCC 7


On 22/09/16 16:57, Paul.Koning@dell.com wrote:
> 
>> On Sep 22, 2016, at 6:17 AM, David Brown <david@westcontrol.com> wrote:
>>
>> ...
>> Your trouble is that your two pointers, cur and end, are pointing at
>> different variables.  Comparing two pointers that are independent (i.e.,
>> not pointing to parts of the same aggregate object) is undefined - the
>> compiler can assume that these two external objects could be anywhere in
>> memory, so there is no way (in pure C) for you to know or care how they
>> are related.  Therefore it can assume that you will never reach "cur ==
>> end".
> 
> Would making them intptr_t instead of pointers fix that?
> 

With care, yes.  But I think it still relies on gcc not being quite as
smart as it could be.  This seems to generate working code, but the
compier could in theory still apply the same analysis:

void rtems_initialize_executive(void)
{
  uintptr_t cur = (uintptr_t) _Linker_set__Sysinit_begin;
  uintptr_t end = (uintptr_t) _Linker_set__Sysinit_end;

  while ( cur != end ) {
    const volatile rtems_sysinit_item *p = (const volatile
rtems_sysinit_item *) cur;
    ( *p->handler )();
    cur += sizeof(p);
  }
}




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