[cfe-commits] Fix search path for clang on latest DragonFly releases [revised patches]

[John Marino]

On 12/20/2012 18:54, Rafael Espíndola wrote:
>>> And no, they should not have an uninitiated variable use :-)
>>
>>
>> As I understood it, both approaches are equivalent and this is simply a
>> preference thing.  The point of what I did was to initialize the variable.
>> Is that not what the code does?  I think I even got that from other clang
>> code.
>>
>> I would have had no problem with you just changing it after the fact if they
>> are indeed equivalent.  I wouldn't have thought that would have been enough
>> to reject the patch.
>>
>> Clang does self-host with this patch, which it did not do before.
>
>> From the documentation
>
> /// @param result Set to true if the file represented by status exists, false if
> ///               it does not. Undefined otherwise.
>
> So it is undefined. If you copied it from somewhere else the other
> place is also wrong if it is not checking the return code.
>
>>
>> By the way, the updated test assumes all changes are added.  I don't intend
>> to patch dragonfly.c for each change.
>
> Given that there are unrelated changes in the patch and that each
> patch should be tested, it looks like you have to.


So that's the sticking point.
The other changes are *not* unrelated.
They are all needed to accomplish getting clang to self-host.
Only applying one patch or the other results in a still-broken clang.

I have no issue resubmitting that same patch set with the USE_GCC47 fix 
you suggest.  I think the patch should be considered together, they 
aren't standalone changes.

John