const volatile behaviour change in GCC 7

Richard Biener richard.guenther@gmail.com
Thu Sep 22 09:34:00 GMT 2016


On Thu, Sep 22, 2016 at 9:58 AM, Andreas Schwab <schwab@suse.de> wrote:
> On Sep 22 2016, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:
>
>> for RTEMS we use linker sets to initialize the system. The following code
>> worked up to GCC 6, but no longer in GCC 7:
>>
>> typedef void ( *rtems_sysinit_handler )( void );
>>
>> typedef struct {
>>   rtems_sysinit_handler handler;
>> } rtems_sysinit_item;
>>
>> rtems_sysinit_item volatile const _Linker_set__Sysinit_begin[0]
>> __attribute__((__section__(".rtemsroset." "_Sysinit" ".begin")))
>> __attribute__((__used__));
>>
>> rtems_sysinit_item volatile const _Linker_set__Sysinit_end[0]
>> __attribute__((__section__(".rtemsroset." "_Sysinit" ".end")))
>> __attribute__((__used__));
>>
>> void rtems_initialize_executive(void)
>> {
>>   const volatile rtems_sysinit_item *cur = _Linker_set__Sysinit_begin;
>>   const volatile rtems_sysinit_item *end = _Linker_set__Sysinit_end;
>>
>>   while ( cur != end ) {
>>     ( *cur->handler )();
>>     ++cur;
>>   }
>> }
>>
>> The corresponding GNU ld linker script section is:
>>
>>     .rtemsroset : ALIGN_WITH_INPUT {
>>         KEEP (*(SORT(.rtemsroset.*)))
>>     } > REGION_RODATA AT > REGION_RODATA_LOAD
>>
>> In GCC 7, the compiler deduces that "cur != end" is always true and
>> generates an infinite loop.
>>
>> Up to GCC 6 the "volatile const" seemed to prevent this optimization.
>
> These qualifiers do not say anything about the variable cur and end
> themselves, only about the values they point to.  As such I don't see
> how they can have any influence on the value of "cur != end".

Yeah, GCC 7 now optimizes pointer comparisons more aggressively.

OTOH I can't reproduce with a simpler

const int a[0];
const int b[0];
int foo ()
{
  return a != b;
}

unless I add 'static' to the vars at which point earlier GCC optimize this
as well.  Eventually you'll hit undefined behavior during loop analysis
as you are accessing a zero-sized array.  But I don't remember this
changing in GCC 7 either.

Richard.

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."



More information about the Gcc mailing list