const volatile behaviour change in GCC 7

[Paul.Koning@dell.com]

> On Sep 22, 2016, at 11:31 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
>>> ...
>>> 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.
>> 
>> 	paul
>> 
> 
> It sounds to me as these are the sort of optimizations that should be
> disabled when compiling with -ffreestanding.

Possibly so.  I dislike workarounds of that form; it seems safer to change the C code to rely on properties called out by the standard.  After all, if an optimization is permitted, it might at some future time be done, and counting on there to be a way to turn off that optimization via a switch, or relying on that switch not changing across releases, isn't as safe.

	paul