[llvm-commits] [compiler-rt] r170429 - in /compiler-rt/trunk/lib/tsan/rtl: tsan_fd.cc tsan_fd.h tsan_interceptors.cc tsan_stat.cc tsan_stat.h

[Chandler Carruth]

On Tue, Dec 18, 2012 at 11:51 PM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Wed, Dec 19, 2012 at 11:45 AM, David Blaikie <dblaikie at gmail.com>wrote:
>
>> On Tue, Dec 18, 2012 at 11:39 PM, Kostya Serebryany <kcc at google.com>
>> wrote:
>> >
>> >
>> > On Wed, Dec 19, 2012 at 11:31 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>> >>
>> >> On Tue, Dec 18, 2012 at 11:26 PM, Dmitry Vyukov <dvyukov at google.com>
>> >> wrote:
>> >> > On Wed, Dec 19, 2012 at 11:05 AM, David Blaikie <dblaikie at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Dec 18, 2012 at 11:03 PM, Dmitry Vyukov <dvyukov at google.com
>> >
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I've fixed the -Wgnu warnings and added -Wgnu to our presubmit
>> >> >> > checks:
>> >> >>
>> >> >> Thanks - though, I'm confused, why would you need to add -Wgnu
>> >> >> anywhere? I was already seeing these warnings (as errors) with Clang
>> >> >> ToT.
>> >> >>
>> >> >
>> >> > Normal build does not do all the checks we need (e.g. check for large
>> >> > stack
>> >> > frames, build with both gcc and clang, build Go runtime syso file,
>> check
>> >> > lint warnings, check parameters of generated machine code, etc).
>> >>
>> >> Rather than adding things incrementally to your custom build - perhaps
>> >> it'd be best to invoke the actual build from your custom build to
>> >> verify that it's still clean? (granted I run the CMake + Ninja build,
>> >> and as with the rest of the LLVM project, it's not expected that
>> >> developers verify both kinds of builds at all times, but both the
>> >> CMake and configure+make builds are kept in sync by their maintainers
>> >> to the best of their ability so keeping one clean should keep the
>> >> other clean assuming you're not directly touching the build files - so
>> >> running at least one of these in your build validation pipeline would
>> >> be rather helpful, rather than trying to replicate the specific flag
>> >> set, etc, there)
>> >
>> >
>> > Alexey is going to add a clang self-hosting build to our bots
>> (post-commit
>> > checking).
>> > Our scripts in tsan-rt do tsan-specific pre-commit checking for tsan-rt
>> > only.
>>
>> Sorry, I'm still a bit confused/missing something. Essentially what
>> I'm trying to understand/correct is:
>>
>> what did I do to build compiler-rt that's different from what you guys
>> are doing?
>>
>> My assumption is it's just that I'm selfhosting Clang and you aren't.
>>
>
> Correct. We mostly used the default build settings which imply using gcc
> as the host compiler.
> If we start using clang as the host compiler, we may break the gcc-based
> build as easily.
> If we start using both it will slowdown the local testing time. Still
> possible.
> Does anyone else use both gcc and clang before commits?
>

The overwhelming majority of developers on both Clang and LLVM use Clang
exclusively for development, and rely on build bots to catch regressions
with GCC.

We try to add warnings to Clang (or turn warnings off in GCC) to minimize
the space where this happens, and so far it's been a fairly successful
pattern. The number of GCC breakages is maybe 2 or 3 times per week for all
of LLVM and Clang, so easily under 1% of commits.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121218/d29b687f/attachment.html>