On Mon, Sep 20, 2010 at 16:12, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > 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. Thanks, Ian--that helps. -Tom
