On Thu, Sep 22, 2016 at 9:58 AM, Andreas Schwab <sch...@suse.de> wrote: > On Sep 22 2016, Sebastian Huber <sebastian.hu...@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, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."