This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: const volatile behaviour change in GCC 7
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Sebastian Huber <sebastian dot huber at embedded-brains dot de>, GCC <gcc at gcc dot gnu dot org>
- Date: Thu, 22 Sep 2016 11:34:29 +0200
- Subject: Re: const volatile behaviour change in GCC 7
- Authentication-results: sourceware.org; auth=none
- References: <57E386D5.1040708@embedded-brains.de> <mvmeg4c5psf.fsf@hawking.suse.de>
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."