www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD buggy optimizing

reply Michael <Michael_member pathlink.com> writes:
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.
Apr 21 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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.
Apr 21 2006
parent reply "Craig Black" <cblack ara.com> writes:
"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
Apr 21 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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.

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
Apr 23 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Apr 28 2006
next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 -----BEGIN PGP SIGNATURE----- iD8DBQFEUzrp3w+/yD4P9tIRAnUYAKCH0fGbAkUPa7SLOwgt/nPhG2TnxQCgtShL yptwVhZKf7OGqVGyohEsZ1g= =oqSk -----END PGP SIGNATURE-----
Apr 29 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
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.
Jun 03 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Apr 29 2006
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
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.

Apr 21 2006
prev sibling parent James Dunne <james.jdunne gmail.com> writes:
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
Apr 21 2006