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.


 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
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