On 2015.04.22 at 00:57 +0200, Hagen Paul Pfeifer wrote: > We see ordinary "template" reuse of common driver code without renaming the > copied static's. But compiled with CONFIG_OPTIMIZE_INLINING=y the inlining is > not respected by gcc: > > atomic_inc: 544 duplicates > rcu_read_unlock: 453 duplicates > rcu_read_lock: 383 duplicates > get_dma_ops: 271 duplicates > arch_local_irq_restore: 258 duplicates > atomic_dec: 215 duplicates > kzalloc: 185 duplicates > test_and_set_bit: 156 duplicates > cpumask_check: 148 duplicates > cpumask_next: 146 duplicates > list_del: 131 duplicates > kref_get: 126 duplicates > test_and_clear_bit: 122 duplicates > brelse: 122 duplicates > schedule_work: 122 duplicates > netif_tx_stop_queue: 115 duplicates > atomic_dec_and_test: 107 duplicates > dma_mapping_error: 105 duplicates > list_del_init: 101 duplicates > netif_stop_queue: 100 duplicates > arch_local_save_flags: 98 duplicates > tasklet_schedule: 76 duplicates > clk_prepare_enable: 71 duplicates > init_completion: 69 duplicates > pskb_may_pull: 67 duplicates > [...] > > Again, the used gcc version is "gcc (Debian 4.9.2-10) 4.9.2". So it is not > outdated nor a legacy one. The inline heuristic seems really broken for some > parts. Is it possible that gcc is bedeviled because of inline assembler > parts which brings confuse the internal scoring system?
I cannot reproduce this issue with my config with 4.8, 4.9 or 5. Could you please come up with a small testcase and open a gcc bug (with full gcc command line)? -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
