Code owner for compiler-rt builtins library?

Howard Hinnant is currently listed as the code owner for the builtins library in compiler-rt. However, Howard has mentioned that he’s no longer active in the community. So I’d like to take a moment to mention my appreciation for all of the hard work Howard put into that role; thank you Howard!

That said, I think it’s time that we pick another code owner for this component because the lack of clear ownership is an issue (both in that code review, and in previous discussions). However, I don’t know compiler-rt well enough to nominate anyone for ownership, and I didn’t spot a clear de facto owner from the git history. So I am asking if anyone has nominations for ownership here.

Alternatively, we could remove Howard as code owner and have no ownership for this component, but I think that leaves a pretty big hole in compiler-rt code review coverage. However, I think this is a better alternative than listing him when he’s no longer active, so if we cannot find an appropriate owner in the next few weeks, I think this is the approach we should go with.

1 Like

Thank you Aaron, I agree. Also, thank you to Howard for all the hard work over the years, beyond compiler-rt, libc++ is also hugely important.

I’m in the same camp as Aaron - I think we need a code owner here, but am not active in this area. Is anyone willing to step forward for consideration, or does anyone have any suggestions for people who might step up?


1 Like

Is there a roadmap for compiler-rt? Splitting into smaller components: sanatizer, the real builtins, …

CC @MaskRay @petrhosek @smithp35 @compnerd

I assume “builtins” here refers to compiler-rt/lib/builtins ? (And maybe compiler-rt/lib/crt, which also doesn’t have anyone noted as code owner.)

tschuett while I personally would love to see the sanitizer runtimes split out into a separate “project” (I mean a top level directory) I don’t know if there is much support for such a change.

@clattner for libc++, I believe that @ldionne has been actively working on that.

I definitely have experience with the builtins but I do t feel comfortable taking a code owner role for the sanitizer runtimes. If it is strictly the builtins then I do not mind.


@compnerd – if you felt comfortable being the owner for just the builtins library, that’d be fantastic. That’s what Howard is currently on the hook for as code owner, so it’s the critical role for us to fill at the moment. I’d happily support your nomination as code owner. :slight_smile:

@AaronBallman ah good, that sounds like that works! BTW, for the sanitizers I think that @kcc (or someone he recommends) would be a good idea.

@compnerd – thanks! I think you’re good to go to replace Howard in the code owners file.

As for the sanitizers, as best I can tell, all of them are already covered by folks in the code owners file, and they all seem reasonably active still. If we need more code ownership changes for those, I think someone should make a new topic here with recommendations on what they’d like to see changed.

1 Like

There’s no official plan to break up compiler-rt as far as I’m aware, but it the idea has been discussed in the past.

One way to come up with a new organization would be to look at dependencies. Specifically, a number of runtimes (even non-sanitizers) depend on compiler-rt/lib/sanitizer_common. Others would benefit from it, see Using C++ and sanitizer_common in profile runtime.

A new organization I could imagine would be:

  • builtins and crt
    • These are already treated specially because they need to be built before any other runtimes and thus cannot have any dependencies, and cannot even use builtin CMake checks.
  • scudo and gwp_asan
    • These have minimal dependencies to enable their use from within C libraries. There’s even a plan for making scudo the default allocator for LLVM libc.
  • asan, cfi, dfsan, hwasan, interception, lsan, memprof, profile, safestack, sanitizer_common, stats, tsan, ubsan, ubsan_minimal, xray
    • All of these are either built on top or could benefit from sanitizer_common and interception libraries. Since not all of these are sanitizers, we may want to consider renaming sanitizer_common to runtime_common.
  • fuzzer
    • This is a standalone library that doesn’t depend on the rest of compiler-rt but does use libc++ could be extracted into its own top-level project.
  • orc
    • This is the same case as fuzzer.
  • BlocksRuntime
    • I’m not sure if this is still being used. There is no CMake build support and it hasn’t been updated in 8 years. Maybe this could be removed altogether?

I’m happy to be an owner for compiler-rt/lib/crt since I implemented that library.

FreeBSD builds and ships BlocksRuntime. It’s needed for various GNUstep things. FreeBSD just builds all of LLVM, including compiler-rt, with its own build system, so doesn’t care about a lack of CMake support. BlocksRuntime/Block.h is also used for the GCD (libdispatch) TSan interceptors.

I think the common denominator between profile, asan, ubsan, memprof, xray is that they are all compiler instrumentation tools. Could sanitizer_common be renamed instrumentation_(utils|base|support) or something like that?

We may also wish to consider aligning our structure with GCC’s libsanitizer fork:

Microsoft also builds and vends sanitizer runtime libraries through MSVC.

Given that two other compilers implement some sanitizer instrumentation tools, it would be worth making their lives a little bit easier to foster collaboration.

1 Like