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

[Douglas Gregor]

Sent from my iPhone

On Mar 3, 2010, at 8:16 AM, Tony Arkles <t.arkles+clang at gmail.com>  
wrote:

> 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 :).

O(lg N) :)

> 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...)

It's slightly more involved, but you can continue your binary search  
within a file by splitting it into two .c files, and moving functions  
between them.
>


Eventually, it will get to the point where you are looking at assembly  
or LLVM IR, but you want to only do that for a small number of  
functions.