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

NAKAMURA Takumi geek4civic at gmail.com
Thu Nov 22 02:21:05 PST 2012


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



More information about the llvm-commits mailing list