This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc version 4.6.0 20100908 (experimental) (GCC) Fails to Build Python 2.7


Tom Browder <tom.browder@gmail.com> writes:

> On Fri, Sep 17, 2010 at 16:42, Tom Browder <tom.browder@gmail.com> wrote:
>> On Fri, Sep 17, 2010 at 06:05, Tom Browder <tom.browder@gmail.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]