On 11 November 2013 23:11, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 11/11/2013 23:38, Peter Maydell ha scritto: >> If we have other places where we're relying on dead code elimination >> to not provide a function definition, please point them out, because >> they're bugs we need to fix, ideally before they cause compilation >> failures. > > I'm not sure, there are probably a few others. Linux also relies on the > idiom (at least KVM does on x86).
Linux is notoriously tied to a particular compiler. I don't think QEMU should be. >> Huh? The point of stub functions is to provide versions of functions >> which either need to return an "always fails" code, or which will never >> be called, but in either case this is so we can avoid peppering the >> code with #ifdefs. The latter category is why we have stubs which >> do nothing but call abort(). > > There are very few stubs that call abort(): You missed some more in stubs/, as it happens. > Calling abort() would be marginally better than returning 0, but why > defer checks to runtime when you can let the linker do them? Because you can't guarantee that the compiler will always throw the code out. As we can see here. > Code which relies on dead-code-elimination is not broken, it's relying > on the full power of the toolchain to ensure bugs are detected as soon > as possible, i.e. at build time. If you can point me at gcc and clang documentation that says "we guarantee that we will dead-code eliminate these classes of conditional at all levels of optimization" then I'm happy that we can continue doing this and we have a clear level of what we require that we're aiming at. If you can't then we're relying on undocumented compiler behaviour and we should stop. > It's very obviously a random tweak aimed at a specific compiler's bug in > dead-code elimination, I'm not denying that. It's not a compiler bug. It's just not applying an optimization in all the cases it possibly could. "Not as optimal as theoretically possible" happens all the time for compilers. I really don't see why anybody wants to rely on undocumented compiler behaviour when the fix which means we have entirely well defined behaviour is a single function in an already existing stub file. What are the downsides here? -- PMM
