Is it possible to mark a certain section of code as not optimizing? My program works fine in debug mode but then when I use the release build it refuses to work, and there is no way for me to debug it either.

If we could mark a certain section of code as "dont optimize" then this would solve the problem. I know rougly where the problem is, but not exactly.

Michael wrote:
> Is it possible to mark a certain section of code as not optimizing? My program
> works fine in debug mode but then when I use the release build it refuses to
> work, and there is no way for me to debug it either.
> 
> If we could mark a certain section of code as "dont optimize" then this would
> solve the problem. I know rougly where the problem is, but not exactly.
> 

You really need to provide more info. than that... Compiler switches, post some code showing exactly where it quits working or ideally isolate the problem down to as few lines of code as you can, etc.

"Dave" <Dave_member@pathlink.com> wrote in message news:e2apq1$2uo7$1@digitaldaemon.com...
> Michael wrote:
>> Is it possible to mark a certain section of code as not optimizing? My
>> program
>> works fine in debug mode but then when I use the release build it refuses
>> to
>> work, and there is no way for me to debug it either.
>>
>> If we could mark a certain section of code as "dont optimize" then this
>> would
>> solve the problem. I know rougly where the problem is, but not exactly.
>>
>
> You really need to provide more info. than that... Compiler switches, post some code showing exactly where it quits working or ideally isolate the problem down to as few lines of code as you can, etc.

Yes, but who knows when Walter will get around to fixing it?  Compler optimization is by nature complex and error prone.  I think being able to selectively optimize is a good idea.  This will allow us to identify optimization bugs more easily.

-Craig

The most finely grained optimization selection is at the file level.  That is, you can select which files you want optimized if you compile them individually.

Then, if possible, break out the code you think may be causing the issue into a separate file and compile it w/o optimizations.  Keep in mind that you can take the affected function bodies out and put them in another file by the same name and module heading, and keep the function signatures in the original file, so although they will compile seperately, when you link them, they'll be part of the same module.

~John Demme

Michael wrote:

> 
> Is it possible to mark a certain section of code as not optimizing? My program works fine in debug mode but then when I use the release build it refuses to work, and there is no way for me to debug it either.
> 
> If we could mark a certain section of code as "dont optimize" then this would solve the problem. I know rougly where the problem is, but not exactly.

Michael wrote:
> Is it possible to mark a certain section of code as not optimizing? My program
> works fine in debug mode but then when I use the release build it refuses to
> work, and there is no way for me to debug it either.
> 
> If we could mark a certain section of code as "dont optimize" then this would
> solve the problem. I know rougly where the problem is, but not exactly.
> 
> 

A quick answer to your problem would be to mark the code as volatile. Like so:

volatile {
	my += code;
	that.should(not);
	be.optimized!();
}

I'm not sure if this actually *does* turn off optimization for the code in question, but in general it would be a bad idea for a compiler to apply optimizations to volatile code.  I'll have to check the DMD implementation for this later.

-- 
Regards,
James Dunne

Craig Black wrote:
> "Dave" <Dave_member@pathlink.com> wrote in message news:e2apq1$2uo7$1@digitaldaemon.com...
>> Michael wrote:
>>> Is it possible to mark a certain section of code as not optimizing? My program
>>> works fine in debug mode but then when I use the release build it refuses to
>>> work, and there is no way for me to debug it either.
>>>
>>> If we could mark a certain section of code as "dont optimize" then this would
>>> solve the problem. I know rougly where the problem is, but not exactly.
>>>
>> You really need to provide more info. than that... Compiler switches, post some code showing exactly where it quits working or ideally isolate the problem down to as few lines of code as you can, etc.
> 
> Yes, but who knows when Walter will get around to fixing it?  Compler optimization is by nature complex and error prone.  I think being able to selectively optimize is a good idea.  This will allow us to identify optimization bugs more easily.
> 
> -Craig 
> 

Yea, but that could substantially increase the complexity of the
compiler and cause more bugs, not to mention how I'd hate to maintain D
code marked up by all those "pragma-like" things, remove one, retest,
remove another, retest, etc... <g>

And IMO Walter is better at fixing that sort of thing than any compiler vendor I've seen.

I guess I assumed that what the OP really needed was help with the program source code (I've done this myself where I could swear a compiler switch was buggy only to find it was my code).

IMHO, the burden-of-proof would be on the person reporting a bug
before they assume that it is a buggy compiler switch ;)

- Dave

Dave wrote:
> Craig Black wrote:
>> Yes, but who knows when Walter will get around to fixing it?  Compler optimization is by nature complex and error prone.  I think being able to selectively optimize is a good idea.  This will allow us to identify optimization bugs more easily.

For about 999 cases out of 1000, the test case can be whittled down to 10 or fewer lines of code, simply by whacking out stuff and seeing if the bug remains. Once the minimal test case is so identified, fixing it is usually not too bad.


> Yea, but that could substantially increase the complexity of the
> compiler and cause more bugs, not to mention how I'd hate to maintain D
> code marked up by all those "pragma-like" things, remove one, retest,
> remove another, retest, etc... <g>

The D optimizer is the same one as the DMC++ one that has been around for 20 years and several hundred thousand users. I run across an actual optimizer bug maybe once a year now. D benefits a lot from its maturity.

Many "optimizer" bugs turn out to be code bugs that exhibit different behavior when the optimizer rearranges things, hence it may appear to "work" unoptimized and fail optimized. The classic example of that is a wild pointer.

Walter Bright schrieb am 2006-04-29:
> The D optimizer is the same one as the DMC++ one that has been around for 20 years and several hundred thousand users. I run across an actual optimizer bug maybe once a year now. D benefits a lot from its maturity.
>
> Many "optimizer" bugs turn out to be code bugs that exhibit different behavior when the optimizer rearranges things, hence it may appear to "work" unoptimized and fail optimized. The classic example of that is a wild pointer.

PASS (no flag) -> FAIL (-O) http://dstress.kuehne.cn/run/bug_cg87_2393_A.d http://dstress.kuehne.cn/run/bug_cg87_2393_B.d http://dstress.kuehne.cn/run/bug_cg87_2393_C.d http://dstress.kuehne.cn/run/bug_cg87_2393_D.d http://dstress.kuehne.cn/run/c/cdouble_01_A.d http://dstress.kuehne.cn/run/c/cfloat_02_A.d http://dstress.kuehne.cn/run/r/real_26_B.d http://dstress.kuehne.cn/run/r/real_26_C.d http://dstress.kuehne.cn/run/r/real_26_D.d

PASS (no flag) -> ERROR (-inline)
http://dstress.kuehne.cn/run/for_04.d
http://dstress.kuehne.cn/run/for_05.d
http://dstress.kuehne.cn/run/foreach_28.d
http://dstress.kuehne.cn/run/foreach_29.d

PASS (no flag) -> FAIL (-inline) http://dstress.kuehne.cn/run/i/if_14_A.d http://dstress.kuehne.cn/run/i/if_14_H.d http://dstress.kuehne.cn/run/i/inline_10_A.d http://dstress.kuehne.cn/run/i/inline_13_A.d http://dstress.kuehne.cn/run/i/inline_14_A.d

FAIL (no flag) -> PASS (-inline) http://dstress.kuehne.cn/run/m/mixin_14_A.d http://dstress.kuehne.cn/run/m/mixin_14_B.d http://dstress.kuehne.cn/run/m/mixin_14_C.d http://dstress.kuehne.cn/run/m/mixin_14_D.d

Thomas

Craig Black wrote:
> 
> Yes, but who knows when Walter will get around to fixing it?  Compler optimization is by nature complex and error prone.  I think being able to selectively optimize is a good idea.  This will allow us to identify optimization bugs more easily.

It's kind of a hack, but if you have a block of code you don't want optimized you could wrap it in a volatile block.


Sean

Walter Bright wrote:
> 
> The D optimizer is the same one as the DMC++ one that has been around for 20 years and several hundred thousand users. I run across an actual optimizer bug maybe once a year now. D benefits a lot from its maturity.
> 

I think the DMD optimizer is great for integer stuff, especially considering the great performance of the compiler itself. My only complaints are that for some/many floating point operations, the FP registers are not used as they could be. This is frustrating especially since D does not have to live by any of the C/++ "excess precision" rules (so it should make as much use of the 80 bit registers as possible).

3 reasons I care: I'd like to flip the -O switch and know I'm getting great code generated whether or not it's int or FP. Also, I don't want to spend a lot of time tweaking things. The other reason is I don't want DMD (and by extension D) to be unreasonably dismissed because of some perceived issue in this area.