Il 12/11/2013 16:13, Peter Maydell ha scritto: >>> >> >>> >> -O1 then for clang. >> > >> > We can even test in configure for the exact optimizations we want, in >> > fact. But I think -O1 doesn't sacrifice debuggability that much: > I'm afraid I still don't see why you'd want to sacrifice it > at all,
Is this FUD or do you have examples of bad debuggability of -O1 code? Personally, I've not even used -O0 for several years. -O2 debuggability is still awful but has improved a lot. If it's not enough, 99% of the time it means that tracing or printf are a better tool for the bug. > when the alternative is "provide a three line stub > function in a file we already have all the build machinery > to compile in the config where it's needed". I just don't > see why you'd worry about the fact that there's no longer > a compile error if you try to call this obviously kvm > specific function in a non-kvm-enabled code path, when > we already have large numbers of kvm-specific functions > that have stubs Most of these stubs do _not_ abort(), they return a sensible error code or should be no-ops in the non-KVM case. > (and when in general, eg QOM APIs, we seem > to be entirely happy to have things be runtime errors rather > than compile time). We're far from having consensus on that, indeed. Paolo
