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). > 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(): int kvm_cpu_exec(CPUState *cpu) { abort(); } int kvm_set_signal_mask(CPUState *cpu, const sigset_t *sigset) { abort(); } Calling abort() would be marginally better than returning 0, but why defer checks to runtime when you can let the linker do them? >>> I wouldn't be surprised if this also affected debug gcc >>> builds with KVM disabled, but I haven't checked. >> >> No, it doesn't affect GCC. See Andreas's bug report. Is it a bug or a >> feature? Having some kind of -O0 dead-code elimination is definitely a >> feature (http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02443.html). > > That patch says it is to "speed up these RTL optimizers and by allocating > less memory, reduce the compiler footprint and possible memory > fragmentation". So they might investigate it as a performance > regression, but it's only a "make compilation faster" feature, not > correctness. Code which relies on dead-code-elimination is broken. There's plenty of tests in the GCC testsuite that rely on DCE to test that an optimization happened; some of them at -O0 too. So it's become a GCC feature in the end. 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. >> I am okay with Andreas's patch of course, but it would also be fine with >> me to split the "if" in two, each with its own separate break statement. > > I think Andreas's patch is a bad idea and am against it being > applied. It's very obviously a random tweak aimed at a specific > compiler's implementation of dead-code elimination, and it's the > wrong way to fix the problem. It's very obviously a random tweak aimed at a specific compiler's bug in dead-code elimination, I'm not denying that. But the same compiler feature is being exploited elsewhere. >> Since it only affects debug builds, there is no hurry to fix this in 1.7 >> if the approach cannot be agreed with. > > ?? Debug builds should absolutely work out of the box -- if > debug build fails that is IMHO a release critical bug. Debug builds for qemu-system-{i386,x86_64} with clang on systems other than x86/Linux. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html