https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64685
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |lto, wrong-code Priority|P3 |P1 CC| |hubicka at gcc dot gnu.org, | |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Summary|wrong code by LTO on |[5 Regression] wrong code |x86_64-linux-gnu |by LTO on x86_64-linux-gnu --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- Esp. mixing -O0 and -O1+ will have interesting effects for sure. Also mixing IL changing options like -fwrapv, -fstrict-overflow, etc. We just check /* Don't inline a function with a higher optimization level than the caller. FIXME: this is really just tip of iceberg of handling optimization attribute. */ else if (caller_tree != callee_tree) { if (((opt_for_fn (e->caller->decl, optimize) > opt_for_fn (callee->decl, optimize)) || (opt_for_fn (e->caller->decl, optimize_size) != opt_for_fn (callee->decl, optimize_size))) /* gcc.dg/pr43564.c. Look at forced inline even in -O0. */ && !DECL_DISREGARD_INLINE_LIMITS (callee->decl)) { e->inline_failed = CIF_OPTIMIZATION_MISMATCH; inlinable = false; } } but that's definitely not enough (unless I miss checks somewhere else but in can_inline_edge_p). Also it's not possible to inline -O1+ into a -O0 function (SSA coalescing). And the !DECL_DISREGARD_INLINE_LIMITS is definitely bogus as well.