This is the mail archive of the
mailing list for the GCC project.
Re: const volatile behaviour change in GCC 7
On September 22, 2016 5:20:56 PM GMT+02:00, Paul.Koning@dell.com wrote:
>> On Sep 22, 2016, at 11:16 AM, David Brown <firstname.lastname@example.org>
>> On 22/09/16 16:57, Paul.Koning@dell.com wrote:
>>>> On Sep 22, 2016, at 6:17 AM, David Brown <email@example.com>
>>>> Your trouble is that your two pointers, cur and end, are pointing
>>>> different variables. Comparing two pointers that are independent
>>>> not pointing to parts of the same aggregate object) is undefined -
>>>> compiler can assume that these two external objects could be
>>>> memory, so there is no way (in pure C) for you to know or care how
>>>> are related. Therefore it can assume that you will never reach
>>> Would making them intptr_t instead of pointers fix that?
>> With care, yes. But I think it still relies on gcc not being quite
>> 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;
>I would not expect the compiler to apply pointer rules for code like
>this. (u)intptr_t is an integer type; it happens to be one whose width
>is chosen to match the width of pointers on the platform in question,
>but that doesn't change the fact the type is integer. For example, it
>is perfectly valid for an intptr_t variable to contain values that
>could not possibly be pointers on a given platform.
I can't see how it could either. BTW your testcase contains another fragility, the order of two global vars.