http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763
--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> 2011-04-26 13:20:24 UTC --- > We should defer detection of incompatibilities to when we see the call stmt, > thus expand_call_inline. We shouldn't worry about this disturbing inliner Undoing the inliner decisions at expand_call_inline is not trivial. 1) We would have to turn inline clone back to offline copy of the function if one doesn't exist. 2) Doing so would resoult in duplicated offline copies of function when such copy really exist but WPA made it static and put into a different partition. 3) With the inliner analysis being able to figure out what references and calls will be optimized out in particular inline clone based on knowledge of its argument, there is no way to output those references (they might refer things not exported from different WPA partitions). So the offline clone would have to be clone with the constants figured out by the inliner propagated in. I am not sure if those are all problems, but I guess we can go this way, but it is remarkably ugly. Also we need smilar kind of validation for ipa-prop. Jump functions will get confused on calls with mismatching types. This would mean that the constant propagation trick above might fail making things even more messy (ie. propagating constant into a structure argument or so). Honza
