Weirdo gcc 4.3.x behaviour

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > Has anyone else seen weird behaviour from the gcc 4.3 branch?
 > 
 > I've tried gcc-4.3.2 + patch and also gcc-4.3.5, both of which behave
 > differently with this change in the kernel:
 > 
 > (asm-generic/pgtable-nopud.h)
 > static inline int pgd_none(pgd_t pgd)           { return 0; }
 > static inline int pgd_bad(pgd_t pgd)            { return 0; }
 > static inline int pgd_present(pgd_t pgd)        { return 1; }
 > 
 > and subsequently adding:
 > +#define pgd_none(pgd)          0
 > +#define pgd_bad(pgd)           0
 > +#define pgd_present(pgd)       1
 > 
 > This causes completely unrelated functions to be optimized differently,
 > as can be seen via the bloat-o-meter:
 > 
 > add/remove: 0/0 grow/shrink: 3/1 up/down: 20/-4 (16)
 > function                                     old     new   delta
 > shmem_file_aio_read                          820     832     +12
 > select_task_rq_fair                         1824    1828      +4
 > kswapd                                      1816    1820      +4
 > elf_core_dump                               3264    3260      -4
 > 
 > The strange thing is that (eg) elf_core_dump() doesn't use any of these
 > macros - and the changes seem to be completely unrelated too:
 > 
 > c00f8cc8:       ea00018c        b       c00f9300 <elf_core_dump+0xc38>
 > c00f8ccc:       e3a05000        mov     r5, #0  ; 0x0
 > c00f8cd0:       e50b508c        str     r5, [fp, #-140]
 > c00f8cd4:       e50b5088        str     r5, [fp, #-136]
 > c00f8cd8:       ea000167        b       c00f927c <elf_core_dump+0xbb4>
 > 
 > vs
 > 
 > c00f8cb4:       ea00018d        b       c00f92f0 <elf_core_dump+0xc3c>
 > c00f8cb8:       e3a00000        mov     r0, #0  ; 0x0
 > c00f8cbc:       e1a05000        mov     r5, r0
 > c00f8cc0:       e50b008c        str     r0, [fp, #-140]
 > c00f8cc4:       e50b0088        str     r0, [fp, #-136]
 > c00f8cc8:       ea000167        b       c00f926c <elf_core_dump+0xbb8>
 > 
 > and:
 > 
 > c00f8d18:       e1a08000        mov     r8, r0
 > c00f8d1c:       e2580000        subs    r0, r8, #0      ; 0x0
 > c00f8d20:       e50b008c        str     r0, [fp, #-140]
 > c00f8d24:       050b0088        streq   r0, [fp, #-136]
 > c00f8d28:       0a00013e        beq     c00f9228 <elf_core_dump+0xb60>
 > 
 > vs
 > 
 > c00f8d08:       e1a08000        mov     r8, r0
 > c00f8d0c:       e2581000        subs    r1, r8, #0      ; 0x0
 > c00f8d10:       e50b108c        str     r1, [fp, #-140]
 > c00f8d14:       050b1088        streq   r1, [fp, #-136]
 > c00f8d18:       0a00013e        beq     c00f9218 <elf_core_dump+0xb64>
 > 
 > The changes seem to be minor register allocation differences, but what
 > worries me is why should this change when these functions don't go
 > anywhere near the page table accessors.
 > 
 > I've had these kinds of changes happen in snd_pcm_hw_rule_ratdens(),
 > which definitely has nothing to do with page tables as a result of
 > changing the way page tables are accessed.
 > 
 > The issue here is that with this noise created by the compiler, it's
 > not possible to properly evaluate the effect of these kinds of changes
 > to the page tables - and I'm wondering if this could be related to the
 > mysterious crashes and MMC read corruption I've seen on Versatile due
 > to the L2x0 changes which have been appearing and disappearing on me
 > recently.
 > 
 > What I'm worried about is if unrelated functions can influence the
 > optimization of following functions, is it possible that some
 > optimizations are mis-applied, leading to incorrect code generation -
 > which would make gcc 4.3 an untrustworthy compiler.

Please prepare a self-contained user-mode test case and open a
gcc bugzilla entry with the test case attached.