On Fri, 2007-11-16 at 15:59 +0000, Jamie Lokier wrote: > Heikki Lindholm wrote: > > J. Mayer kirjoitti: > > >Some may have experienced of having some Qemu builds crashing, > > >apparently at random places, but in a reproducable way. > > >I found one reason for this crashes: it appears that with the growth of > > >the op.c file, there may be cases where we could reach the inlining > > >limits of gcc. In such a case, gcc would not inline some declared > > >"inline" function but would emit a call and provide a separate function. > > >Unfortunately, this is not acceptable in op.o context as it will > > >slowdown the emulation and because the call is likely to break the > > >specific compilation rules (ie reserved registers) used while compiling > > >op.o > > > > Does -winline give a warning when this happens? > > And can it be repaired with __attribute__((__always_inline__))?
As I already reported in the previous message, this helps solve the problem but is not sufficient. Please refer to the proposed patches and the rest of the discussion. Further invastigation also showed me that there may be problems while compiling translate-op.c. It seems the solution would be to change the gcc inlining limits into the BASE_CFLAGS too _and_ define functions in dyngen.h as always_inline. This would also avoid most inline related warnings during the compilation (but maybe not solve all cases, as seen in the op.c case). Reading gcc source code showed me there are cases where a function could be not inline when marked 'inline' without generating any warning message. What I don't know is if those cases are likely to happen during normal compilations, but as the op.c compilation seems to be buggy and never emit those warnings, I guess we can reach those cases. -- Jocelyn Mayer <[EMAIL PROTECTED]>
