https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873
--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> --- The diff in flags is the following: not inlinable: bar/1 -> memcpy/0, optimization level attribute mismatch align_functions (0/0x10) align_jumps (0/0x10) align_loops (0/0x10) flag_vect_cost_model (0x2/0x1) optimize (0x3/0x2) flag_associative_math (0x1/0) flag_cx_limited_range (0x1/0) flag_finite_math_only (0x1/0) flag_gcse_after_reload (0x1/0) flag_inline_functions (0x1/0) flag_ipa_cp_clone (0x1/0) flag_errno_math (0/0x1) flag_predictive_commoning (0x1/0) flag_reciprocal_math (0x1/0) flag_signed_zeros (0/0x1) flag_trapping_math (0/0x1) flag_tree_loop_distribute_patterns (0x1/0) flag_tree_loop_vectorize (0x1/0) flag_tree_partial_pre (0x1/0) flag_tree_slp_vectorize (0x1/0) flag_unsafe_math_optimizations (0x1/0) flag_unswitch_loops (0x1/0) so we fail because of errno-math difference. The logic accepting/rejecitng inlines in can_inline_edge_p and I guess it is the fact that we are affraid to inline safe math to unsafe. I think certain combinations of flag will trigger ICE, such as one enabling/disabling vector builtins. But I suppose we may want to bypass majority of the checks for case we have always_inline w/o explicit optimization attribute indeed, but only at early inlining time, probably not at LTO? At LTO time we already did transformation that turn previously correct code with target's optimization flags to be incorrect (i.e. -fstrict-aliasing blocks some transformations we may do during early opts)
