On Tue, Apr 03, 2012 at 06:43:51AM +0300, Karri Kaksonen wrote: > Any ideas of how to pinpoint this? The easiest idea (for you :-) is to send me the code, so I can try to track it down. Another idea is to do what I will do if you send me the code: * First check if the problem disappears with other values of --codesize. If so, compare the generated assembly code. * Then, generate a list of the optimization steps applied by the compiler. This is done with "cc65 --list-opt-steps". Feed this into a text file. * Prepend a '-' before the first half of the steps, then run cc65 on your code, adding "--debug-opt filename" to the command line. "filename" is the name of the file containing the optimization steps created in the last step. * Using a sort of binary search, try to nail down the problem to one optimization step. Binary search means: If the problem disappear when disabling half of the steps, it must have been caused by one of the disabled steps. So re-enable half of them and retry. Repeat until one step is left. Compare the generated assembly with and without this step. If this sounds complicated, you may want to take comfort in the fact that it's even more complicated in reality:-) Some steps depend on others, and sometimes a bug is caused by a combination of steps, which can be quite confusing. It can mean for example that the bug is gone when disabling one of of the optimization steps and it is also gone when disabling the other half:-) So if you are able to avoid above procedure, then do it:-) For example by changing the code slightly. If the bug disappears, compare the generated code around the point where the C code has changed. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue Apr 3 14:53:10 2012
This archive was generated by hypermail 2.1.8 : 2012-04-03 14:53:13 CEST