[Bug lto/64685] [5 Regression] wrong code by LTO on x86_64-linux-gnu
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Jan 20 09:51:00 GMT 2015
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.
More information about the Gcc-bugs
mailing list