Re: Debug optimized code

Stephen Horne <sh006d3592@blueyonder.co.uk>
Mon, 22 Sep 2008 04:43:42 +0100

          From comp.compilers

Related articles
[3 earlier articles]
Re: Debug optimized code walter@bytecraft.com (Walter Banks) (2008-09-17)
Re: Debug optimized code rcmetzger@grandecom.net (rcmetzger) (2008-09-17)
Re: Debug optimized code sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-18)
Re: Debug optimized code barry.j.kelly@gmail.com (Barry Kelly) (2008-09-19)
Re: Debug optimized code gneuner2@comcast.net (George Neuner) (2008-09-20)
Re: Debug optimized code DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-09-21)
Re: Debug optimized code sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-22)
Re: Debug optimized code gneuner2@comcast.net (George Neuner) (2008-09-23)
Was: Debug optimized code; Now: How many compiler bugs have you seen? cfc@shell01.TheWorld.com (Chris F Clark) (2008-09-24)
Re: Was: Debug optimized code; Now: How many compiler bugs have you se ArarghMail809@Arargh.com (2008-09-24)
Re: Debug optimized code; Now: How many compiler bugs have you seen? armelasselin@hotmail.com (Armel) (2008-09-24)
Re: Was: Debug optimized code; Now: How many compiler bugs have you se n.pipenbrinck@cubic.org (Nils) (2008-09-25)
Re: Was: Debug optimized code; Now: How many compiler bugs have you se sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-25)
[10 later articles]
| List of all articles for this month |

From: Stephen Horne <sh006d3592@blueyonder.co.uk>
Newsgroups: comp.compilers
Date: Mon, 22 Sep 2008 04:43:42 +0100
Organization: virginmedia.com
References: 08-09-076 08-09-105
Keywords: debug
Posted-Date: 23 Sep 2008 14:07:13 EDT

On Sat, 20 Sep 2008 04:28:36 -0400, George Neuner
<gneuner2@comcast.net> wrote:


>And please don't debug code at one level and then crank up the
>optimization for a production compile. Your ship code should always
>be exactly what you've debugged.


I disagree.


Your ship code should always be what you've tested.


You debug to diagnose bugs - not to detect them. Probably 99% of
errors in new code are simple logic errors. Around 99% of those behave
identically whether the optimiser is on or off.


So you automate your unit tests, write them according to what you
expect from the code (as opposed to what it delivers) and run them
religiously on both your debug and release versions. When both fail
identically (as they normally do), you usually have a good idea what's
wrong anyway, but if you don't then that's the time for the debugger.


If you "test" your code by running the debugger, odds are you see
nothing different to what you had in mind when you wrote the code. Of
course you can catch a few bugs this way, but it's very unproductive.
It takes at least as long as writing and running a few unit tests, but
you don't get anything repeatable at the end. You have no guarantee
that the same or similar bugs won't get through undetected in the
future.


With unit tests, you even get that immediately useful hint when the
debug and release versions behave differently. 99.9% of the time
(unless you're using a really crappy compiler) this tells you that
someone's doing something stupid with a pointer.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.