On 16/11/2007, Jocelyn Mayer <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-11-16 at 15:52 +0000, Paul Brook wrote: > > > Then, I choosed to replace 'inline' by 'always_inline', which is more > > > invasive but have less risks of side effects. The diff is attached in > > > always_inline.diff. > > > The last thing that helps solve the problem is to change the inlining > > > limits of gcc, at least to compile the op.o file. > > > > Presumably we only need one of the last two patches? It seems rather > > pointless > > to have always_inline *and* change the inlining heuristics. > > >From the tests I made, it seems that adding always_inline helps but > unfortunatelly does not solve all cases. Should check in the gcc source > code why it is so... > > > I'm ok with using always_inline for op.o (and things it uses directly) as > > this > > is required for correctness. I'm not convinced that that using always_inline > > everywhere is such a good idea. > > That's exactly what I did: I changed 'inline' to 'always_inline' in > headers that are included by op.c, I did not made any change in other > headers.
I think a line like #define inline __attribute__ (( always_inline )) inline in dyngen-exec.h should be enough? Regards