Tom Browder <tom.browder@xxxxxxxxx> writes: > On Fri, Sep 17, 2010 at 16:42, Tom Browder <tom.browder@xxxxxxxxx> wrote: >> On Fri, Sep 17, 2010 at 06:05, Tom Browder <tom.browder@xxxxxxxxx> wrote: >>> The subject says it all. ÂThe build works with released gcc version >>> 4.5.1. ÂThe Python folks say that a pyc file gets corrupted somehow. > > As a next debugging step I plan to try to compare asm output for the > source files in question, but is it a waste of time for a novice due > to too many changes between compiler versions? Probably, yes. > Looking for any help or hints in the proper direction to head for debugging. If you have a repeatable test case, study it until you understand exactly why it fails. This often means running it under the debugger over and over again. I don't know of any good way to skip this step. If you don't have a repeatable test case, then you could try a hail mary like comparing asm output, but I wouldn't hold out much hope. 9 times out of 10 breaking with a new compiler version is due to a case where the code relies on behaviour that is undefined according to the C standard, and where some compiler optimization has become more aggressive. 1 time out of 10 it is a compiler bug. So one approach is, once you have a general idea of which code is behaving badly, look at it to see if there are any potential aliasing violations or cases where the code depends on defined signed overflow. Ian
