On Sunday, February 24, 2013 09:33:12 deadalnix wrote: > On Sunday, 24 February 2013 at 08:16:37 UTC, Jonathan M Davis > > wrote: > > On Sunday, February 24, 2013 08:58:38 deadalnix wrote: > >> I would bet for register promotions, dead read/write > >> eliminations > >> and alike. I don't expect inline to be part of it. > > > > It would actually be problematic if it were, because it would > > screw with > > debugging. > > > > - Jonathan M Davis > > Does disabling optimization imply debug build ?
Well, there are three aspects to what usually is meant by a debug build: 1. Debug symbols are compiled in. 2. Optimizations are not enabled. 3. Assertions _are_ enabled. For dmd, the first one is controlled by -g and -gc, the second one is controlled by -O (and probably to some extent by -release), and the third one is controlled by -release (and to some extent -noboundscheck). But what it actually means for a build to be "debug" or "release" really isn't all that well defined. It pretty much just boils down to one of them being compiled for debugging and development purposes, whereas the other is what's used in released code. In general though, when people compile release builds, they use all of the various flags for enabling optimizations and disabling debug symbols and assertions, whereas when they compile debug builds, they disable all optimizations and enable debugging symbols and assertions. But as for inlining, enabling it (or any other optimizations) screw with debugging, so they shouldn't be used with any builds which are intended for debugging, and with the way most compilers' flags work, optimizations aren't enabled unless you ask for them, making debug builds the default. - Jonathan M Davis
