dmd 1.048 and 2.033 releases

Denis Koroskin 2korden at gmail.com
Tue Oct 6 14:06:31 PDT 2009


On Wed, 07 Oct 2009 00:54:22 +0400, grauzone <none at example.net> wrote:

> Jarrett Billingsley wrote:
>> On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
>> <newshound1 at digitalmars.com> wrote:
>>> Lutger wrote:
>>>> Walter Bright wrote:
>>>>
>>>>> Don wrote:
>>>>>> It's pretty standard, though. For example, there are some bugs which
>>>>>> Visual C++ detects only when the optimiser is on. From memory, they  
>>>>>> are
>>>>>> all flow-related. The MS docs recommend compiling a release build
>>>>>> occasionally to catch them.
>>>>> The flow analysis could be run on every compile by default, but it  
>>>>> would
>>>>> make for pretty slow turnaround.
>>>> Is it possible / reasonably to run flow analysis but still have a  
>>>> build
>>>> that can be properly debugged? If yes, wouldn't it be nice to have it  
>>>> as a
>>>> separate compiler option? Some people with build slaves, fast cpu's or
>>>> smallish projects won't care that much for the performance.
>>> Just compile with:
>>>        -debug -O
>>  You don't seem to be grasping the issue here. It's not using -O with
>> -debug that's the problem, it's using it with -g. You can't reasonably
>> expect someone to put an optimized executable through a debugger.
>
> As I understand, -0 just enables flow analysis (which is slow and thus  
> shouldn't be run normally), not full optimization.

No, -O means "optimize". It's just much easier to check code flow when an  
executable is optimized, that's it.


More information about the Digitalmars-d-announce mailing list