| ??? 07/05/08 05:02 Read: times |
#156405 - Why Is Debugging Optimized Code Such an Issue? |
There is a closed discussion on the subject that caused this doubt in my mind.
If the unoptimal code runs correctly, but the optimized code does not, is not the defect in the compiler? Should not the compiler vendor fix the defect, and in the interim provide a work around? Admittedly, stepping through assembly code, to locate the fault, and maybe fix it by hand, is not an easy, or enjoyable task. But if the developer does not want to develop a test case and pass it to the compiler vendor, that may the best way. |
| Topic | Author | Date |
| Why Is Debugging Optimized Code Such an Issue? | 01/01/70 00:00 | |
| Usually not | 01/01/70 00:00 | |
| False Assumptions | 01/01/70 00:00 | |
| "language specification" ?? | 01/01/70 00:00 | |
| Do not assume it is that easy | 01/01/70 00:00 | |
| Common Stuff Leading To Errors | 01/01/70 00:00 | |
| "common stuff" falling apart when optimized | 01/01/70 00:00 | |
| How broken things work | 01/01/70 00:00 | |
| It is not like that | 01/01/70 00:00 | |
| A bad workman blames his tools | 01/01/70 00:00 | |
| A common side effect of optimisation | 01/01/70 00:00 | |
| Newbies | 01/01/70 00:00 | |
| another good reason | 01/01/70 00:00 | |
| a rule of thumb | 01/01/70 00:00 | |
| excellent advice, however - and | 01/01/70 00:00 | |
| Defeatist? | 01/01/70 00:00 | |
| Or turn it down as needed | 01/01/70 00:00 | |
| Using Pragmas During Debugging | 01/01/70 00:00 | |
| Free lunch? | 01/01/70 00:00 | |
| a dream | 01/01/70 00:00 | |
| If it were easy everone would be doing it. | 01/01/70 00:00 | |
you can't | 01/01/70 00:00 |