--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-26 10:32 ---
The types do not match at gimplification time:
(gdb) call debug_tree (x)
constant invariant 32>
unit size constant invariant 4>
align 32 symtab 0 alias set -1 canonical type 0x2b07ce1fb540 precision 32
mi
--- Comment #2 from mark at codesourcery dot com 2007-06-26 12:14 ---
Subject: Re: [4.3 Regression] attribute always_inline ->
sorry, unimplemented: recursive inlining
rguenth at gcc dot gnu dot org wrote:
> TYPE_ARG_TYPES says we want a char, but the call expression has an int. I
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-26 14:39 ---
The C front-end has the same "wrong type". ./cc1 -funit-at-a-time t.c gives:
t33.c: In function 'f3':
t33.c:2: sorry, unimplemented: inlining failed in call to 'f2': recursive
inlining
t33.c:3: sorry, unimplemented:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-26 14:51 ---
Related to PR 15484, at least that PR is the underlying cause.
For the C front-end the promoting happens in convert_arguments, c-typeck.c.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Can we get a better error message than "recursive inlining", btw? :-)
--
Daniel Jacobowitz
CodeSourcery