On Wed, Oct 21, 2015 at 6:27 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Oct 21, 2015 at 06:22:37PM +0200, Bernd Schmidt wrote: >> On 10/21/2015 06:18 PM, Jeff Law wrote: >> >To avoid conditionally compiled code. I'm of the opinion we should be >> >stomping out as much as we reasonably can. >> >> Yeah, I get that, but the point I'm trying to make is that if you get rid of >> all conditional compilation, you don't need either ENABLE_CHECKING or >> CHECKING_P, because you'll be testing flag_checking. And if some conditional >> compilation remains (let's say in the cumulative_args case), then there's no >> win from changing the spelling from ENABLE_CHECKING to CHECKING_P. > > So, what is the plan with flag_checking? Will --enable-checking=yes vs. > release just affect the default value of that flag, or will it be turned > into 0 for release builds? If the former, I'd at least like to see > a __builtin_expect making it unlikely for the release builds and likely for > the development builds (to match the default value).
My plan is to make flag_checking a runtine controllable value (via -fchecking) so if you run into an issue with a release build you can still do -fchecking with the same build. We can't (and shouldn't) guard everything with flag_checking because the hit on compile-time with flag_checking == 0 will be too big (like the tree checking macros). But for example all the verify_XXX () calls can be safely guarded by flag_checking. So we _do_ want a always-defined ENABLE_CHECKING (or CHECKING_P) to be able to remove conditional compilation for cases where we do not want to do runtime checks for performance reasons. Richard. > Jakub
