[llvm-commits] [llvm] r168181 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineCompares.cpp test/Transforms/InstCombine/icmp.ll

[Pawel Wodnicki]

Hi Takumi,

>> Pawel, pull part of r168196 into release_32, or warnings could be seen.


I do not like seeing warnings either but at this moment it is
a secondary issue to merging of patches fixing problems.


>I don't think having the build be warning free is part of the release
>criteria.
>That said, I've got nothing against pulling r168196, which is risk >free.

 I have queued-up r168196 for processing as Duncan
approved it and it is risk free.

 As for your original request, from the release process perspective:

 I should be getting and processing requests approved
by code owners only :)

 I do no think merging partial patches into the release branch
should be the way we deal with issues unless there is no other
way the to fix a problem.



Pawel


> 2012/11/22 Duncan Sands <baldrick at free.fr>:
>>>> I don't think having the build be warning free is part of the release
>>>> criteria.
>>>
>>>
>>> http://llvm.org/docs/HowToReleaseLLVM.html#release-build
>>>
>>>> The builds of llvm, clang, and dragonegg *must* be free of errors and
>>>> warnings in Debug, Release+Asserts, and Release builds. If all builds are
>>>> clean, then the release passes Build Qualification.
>>
>>
>> this criterion hasn't actually been applied in practice for the last few
>> releases...
> 
> I suppose I have been keeping it in last a few releases.
> (Sometimes it could not be done due to my other tasks, though...)
> 
>>> Now with our mature clang, I think we should keep the tree
>>> warnings-clean to prove clang itself. ;)
>>
>> If you take the release documentation seriously, you will see that you
>> shouldn't
>> be building with clang at all, or even a recent version of gcc:
>>
>> http://llvm.org/docs/HowToReleaseLLVM.html#target-build
> 
> Wow! That section is indeed bitrotten!
> I suppose, in our custom for months, the tree has being kept
> warnings-free by clang.
> AFAIK Google's internal builders are checking the tree with "clang -Werror"
> 
> (And, I have been watching warnings in my builders)
> 
> Now, I also suppose we don't honor gcc's warnings any more.
> 
> Ok, at least I suggest we might clarify "the tree should be
> warnings-free with clang".
> And we should update HowToRelease *in future*. :D
> 
> ...Takumi
> 
>