[Bug tree-optimization/51012] [4.7 Regression] ICE: in fold_convert_loc, at fold-const.c:1897 with -fno-early-inlining and passing incompatible function ptr

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51012

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2011-11-08 13:50:44 UTC ---
On Tue, 8 Nov 2011, jamborm at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51012
> 
> --- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-11-08 13:06:29 UTC ---
> (In reply to comment #2)
> > 
> > What about WPA stage?  I think we don't "fixup" inlinable status of
> > edges at the beginning of ltrans (or inline transform).  Do we?
> 
> No.  And unless this got addressed meanwhile, we don't need indirect
> inlining to hit this bug with LTO (I belive
> https://bugzilla.mozilla.org/show_bug.cgi?id=652563 is a manifestation
> of this problem).  IIRC, Honza had plausible reasons why un-doing
> inlining decisions is tough but we eventually either need that or
> store types of arguments along each call graph edge.

I understand its 'though' because we possibly have thrown away
the offline copy already before committing inline decisions?
But - can't we simply materialize the clone?  (of course that
would be possibly many clones...)

Note that with LTO symbol merging even direct calls may become
un-inlinable (because they change to an incompatible signature).

Note that the idea to _not_ inline in those cases is motivated
to behave exactly the same as if we'd not inline for such
undefined code.  We could certainly fix this up during inlining
itself - as last resort with going through a memory temporary
(ugh).  But we for sure will behave differently than the target
machine for simple integer mode mismatches (note that what we see
on gimple doesn't really reflect the target ABI or what we would
see on RTL ...)