[cfe-dev] clang with Python 3.1 release31-maint

[Tony Arkles]

On Wed, Mar 3, 2010 at 9:19 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
> The typical approach to narrowing down these problems is to compile half of the .o files with GCC and half with Clang, link them together, and see if that works. Continue that binary search down until you've found the small set of .o files that, when compiled with Clang, result in a failure. Then you can debug or start splitting up the file itself to narrow it down to a few function(s) to determine whether it's a Clang mis-compile, or undefined behavior in Python, or something entirely different.
>
>        - Doug

Wow, this is an incredibly productive approach :).

I set Python 3.1 aside and focused directly on expat 2.0.1 (this is
where a lot of the failures with Python were).

- If I compile everything with clang, it segfaults on "make check"
(runs their unit test suite)

- If I compile everything with clang except for lib/xmlparse.c, the
test suite runs but has 3 failures.

- If I compile everything with clang except for lib/xmlparse.c and
lib/xmltok.c, the test suite runs fine...

So we've narrowed it down quite a bit!

I have class and some things to deal with this afternoon, but
hopefully I'll have more time to look at this this evening.

Any advice for next steps?  I haven't really looked into the code
generation bits of clang/llvm yet, but I'm guessing that this will
involve comparing assembler output from gcc and clang? (Which I'm
comfortable with, but a bit concerned because xmlparse.c is a 6k line
file...)

Cheers, thanks for the pointers so far,
Tony