   Compiler Bugs - What to do?
  Hello all, I''ve read that only 3% of bugs are caused by the compiler.  My question is:  When you find one of those 3%, what do you do?I''ve come across one of those times when you have a working project, try to add some code, the code doesn''t work, you comment all of the added code out, rebuild and the project is still broken.In my paticular case the disassessembly calls "INT 3" and my MSVC tells me that a "user defined breakpoint found".  I never defined that!  I have NO breakpoints, especially in assessembly!So does anyone have hard-won tips they''ve found for what to do about a confused compiler?  (Besides revert to an old project that is...I should have made a backup of mine.) Thanks for the help, Void 
  I''ve found, with the VC++ compiler at least, that I get "INTERNAL COMPILER ERROR" on complex lines sometimes (really not that often though).Something like this:CaculateSomething( pMyObjects->GetSomething()->GetSomethingElse()->CalculateMe() );  might cause a compiler error. However, if I break it up (which also makes it a lot more readable) to something like this:CSomething* pSomething = pMyObjects->GetSomething();CSomethingElse* pSomethingElse = pSomething->GetSomethingElse();CThingToCalc* pCalc = pSomethingElse->CalculateMe();CalculateSomething( pCalc );  So, sometimes rearranging things can help. The code still does the same thing, but it''s just arranged differently. ;  sounds like you''re blaming your own error on the compiler.NO compiler will stick an INT 3 in the code randomly, YOU did something. like set a breakpoint there in the debugger. ;  And I''ve read that n% of statistics are made up on the spot (where n > number_big_enough_to_remember_and_quote).I second AP #2.MSVC compilers are usually quite good about this, they scream loudly: "INTERNAL COMPILER ERROR." Other compilers I''ve heard have a history of outputting unreliable code, I cannot vouch for the credibility of that statement though, I have used only g++ 2.95/3.03, MSVC 6,  7, 7.1, and Borland Turbo C++.I have really only ''pushed the limits'' of C++ with the 7.1 release of MSVC, partially because it was finally possible, and partially because I am still learning C++.int 3 in assembler breaks to the debugger. Humor me here but I think I''ve seen VS surround your code with int 3 when you view the disassembly. I can''t verify this, I''m not working on unmanaged code at the moment.Rebuild the solution maybe? ;quote:Original post by Anonymous Poster  sounds like you''re blaming your own error on the compiler.NO compiler will stick an INT 3 in the code randomly, YOU did something. like set a breakpoint there in the debugger.   Agreed.The NT kernel (as found in NT, 2000 and XP) will also insert INT 3 user breakpoints into your program when:- you trash memory you don''t own- read from memory you don''t own- you press F12 when your program is running inside a debuggerTake a look at the debug output window in the debugger. Usually the reason for the breakpoint/error is explained in there.You''ll also find INT3''s put after functions in memory to trap bad longjmp/asm jmp calls.I''ve blamed compilers in the past for some problems - all except one of which turned out to be bugs in my code. I tend to be less quick to jump to illogical conclusions like that these days.If you do think you HAVE found a genuine compiler bug:0) Isolate the cases where it happens and do your best to analyse why. Don''t call it a compiler bug until you can prove it''s not your code. A compiler has had infinately more bug testing by others than your code has - it''s the least likely component to be at fault. 1) Make the simplest possible program/project to demonstrate it. For most issues this will probably just be a 5 or so line source code file. You MUST do this to prove that it IS actually a bug and not something really obscure with the rest of the code.2) Try the demo case with the latest compiler service packs and library versions (the latest PSDK etc).3) Try single stepping the demo/test case in the debugger. What''s happening when the breakpoint occurs.4) Try the demo case with a different compiler, preferably from a different vendor. Beware, this isn''t a substitute for the other steps, just a way of narrowing down the likelyhood of the problem actually being the compiler itself AFTER you''ve proven you can reproduce the issue in a small test case.5) Post the repro/test case source code on a forum like this - 20000 heads are better than 1... No matter how much you think you know about a language or an OS, you don''t know all the caveats, constructs etc. 6) Do an assembly listing. See if there''s any obvious reason. Try single stepping that in the debugger.For stray breakpoints:7) Finally, if all else fails, contact the compiler vendor and let them know. If you haven''t performed extensive testing of your own, you''re likely to end up with egg on your face.- I''ve not had it with the service packed version of MSVC 6- MSVC 6 without the service packs have occasionally lost breakpoints in a few rare cases.- MSVC 4 and MSVC 5 did occasionally "lose" breakpoints you''d set in its IDE. They were still there, the IDE just didn''t show them.- Press CTRL-B to get the breakpoints list - including the watch list. Check it thouroughly.- Delete the Debug/Release folder(s).- Clean & Rebuild All.- Finally create a new project/workspace and copy all the files and folders over.Do you have any links/ISBN/ISSN''s for this "3% of bugs are caused by the compiler" assertion ??. In my personal experience with MSVC it''s been more like 0.003%, maybe 0.03% on some less mature compilers. --Simon O''Connorex  -Creative AsylumProgrammer &Microsoft MVP