http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43218
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-24
15:17:42 UTC ---
They now fail because -flto is now -fwhopr. They are all fixed with
-flto -flto-partition=none.
expand_call_inline ICE:
4043 gcc_assert (gimple_assign_single_p (stmt)
4044 || CONVERT_EXPR_CODE_P (gimple_assign_rhs_code
(stmt)));
(gdb) call debug_gimple_stmt (stmt)
D.2008_1 = (<float:32>) D.2015;
because we inline int f(void) as if it were float f(void). The can-inline-p
check doesn't work in WPA mode as we do not have the call stmt around.
We of course would also ICE during stmt verification if we didn't inline
this function. For non-function decls we wrap them inside MEM_REFs
serving as VIEW_CONVERT_EXPRs, we don't do that for fns because that
caused regressions elsewhere, so a fix is delayed to the point where
we properly preserve the call ABI type for calls.
Ahm, at ltrans stage we have
<addr_expr 0x7ffff7ed6480
type <pointer_type 0x7ffff5d00f18
type <function_type 0x7ffff5d07000 type <real_type 0x7ffff7ef0000>
...
arg 0 <function_decl 0x7ffff5d04800 f
type <function_type 0x7ffff5d00e70 type <integer_type 0x7ffff7ee3498>
for the call fn, so the type is preserved but the addr-expr contains a
mismatch (which verification I disabled for lto).
We could warn or error for ABI incompatible function signatures, but
somebody has to write a proper predicate first.
Hmm, I'll try to fix this up at symbol/cgraph merging time.
