https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82012
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 29 Aug 2017, krebbel at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82012 > > --- Comment #3 from Andreas Krebbel <krebbel at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #1) > ... > > inline int __attribute__((always_inline)) foo () { return 0; } > > int __attribute__((target("soft-float"))) test () { return foo (); } > > > > > > s390 misses to implement TARGET_CAN_INLINE_P. > > Well, but what should the can_inline_p hook answer in that case? Since > soft-float/hard-float is an ABI switch the hook probably should reject > inlining. But that would not be helpful. What about ignoring differences of > target attributes if the callee has been declared "always_inline"? If the > programmer uses always_inline it means that the function is expected to > inherit > the target attributes of the caller. This should be part of the default > implementation of the can_inline_p hook then. Not sure. The user might be deliberately expecting an error when such function is called from wrong target context. The function might contain inline assembly which violates the callers ABI (in this case it might contain hard-float code?). Not sure what the libitm use of soft-float is about here. Note the previous implementation simply treated "no target attribute" as "generic". Somewhat reasonable at first sight but it breaks badly because we do not really know this property and all functions implicitely inherit "target" from the global set options (with LTO that gets explicit to support TUs with different global flags). I'd say it is valid to inline any function not using FP into a function that differs in "soft-float" state? Similar to the patch I did to the x86 backend allowing -mfpmath differences in that case. Would probably fix this particular case. Consider a flag enabling some vector features, -mfancy-vect, building a TU with said flag and inline void __attribute__((always_inline)) foo () { __builtin_fancy_vect_insn (); } void __attribute__((target("no-fancy-vect"))) { return foo (); } with the pre-patched default hook we'd happily inline foo () here (it doesn't have a target attribute!). Note at runtime such inlining should be always valid(?) (arm folks make thumb vs. non-thumb as an example - not sure if the linker needs to insert special dispatch code when transitioning, so it might not be ok in that case!). But as insn patterns are usually guarded with some insn-enablement conditions we'd ICE.
