https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #2 from Denis Vlasenko <vda.linux at googlemail dot com> ---
Tested with gcc-4.9.2. The attached testcase doesn't exhibit the bug, but
compiling the same kernel tree, with the same .config, and then running
nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn
reveals that now other functions get wrongly deinlined:
8 0000000000000028 t acpi_os_allocate_zeroed
7 0000000000000011 t dst_output_sk
7 000000000000000b t hweight_long
5 0000000000000023 t umask_show
5 000000000000000f t init_once
4 0000000000000047 t uni2char
4 0000000000000028 t cmask_show
4 0000000000000025 t inv_show
4 0000000000000025 t edge_show
4 0000000000000020 t char2uni
4 000000000000001f t event_show
4 000000000000001d t acpi_node
4 0000000000000012 t t_stop
4 0000000000000012 t dst_discard
4 0000000000000011 t kzalloc
4 000000000000000b t udp_lib_close
4 0000000000000006 t udp_lib_hash
3 0000000000000059 t get_expiry
3 0000000000000025 t __uncore_inv_show
3 0000000000000025 t __uncore_edge_show
3 0000000000000023 t __uncore_umask_show
3 0000000000000023 t name_show
3 0000000000000022 t acpi_os_allocate
3 000000000000001f t __uncore_event_show
3 000000000000000d t cpumask_set_cpu
3 000000000000000a t nofill
...
...
For example, hweight_long:
static inline unsigned long hweight_long(unsigned long w)
{
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}
wasn't expected by programmer to be deinlined. But it was:
ffffffff81009c40 <hweight_long>:
ffffffff81009c40: 55 push %rbp
ffffffff81009c41: e8 da eb 31 00 callq ffffffff81328820
<__sw_hweight64>
ffffffff81009c46: 48 89 e5 mov %rsp,%rbp
ffffffff81009c49: 5d pop %rbp
ffffffff81009c4a: c3 retq
ffffffff81009c4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
I'm going to find and attach a file which deinlines hweight_long.
