similar to: [Call for Volunteers] Bug triaging

Hi Zach, Thanks for putting the data in a spreadsheet - that’s easier to navigate. And thanks for re-raising the question whether we have the right components in bugzilla. As I think this could be an area for lots of different opinions, without any near-perfect solution, it has the potential to be a discussion that drags on for a long time. I thought half of all bugs not getting triaged was a

Hi Zach, Thanks for elaborating. I like your proposal. I agree it still groups per area of expertise. And it makes the set of components we have easier to manage. Before making changes though I hope to hear opinions from others on this. What do others think? Thanks, Kristof On 9 Nov 2018, at 18:05, Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote: To

I had considered a libraries/Backends:Other as well that would be separate from libraries/Other On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff <dschuff at google.com> wrote: > I wonder if backends are a special case to the heuristic of "let's not > make a bug component for code components that are too small". LLVM is > factored to cleanly separate backend code, to the

As everyone probably realizes, I''m getting swamped with incoming problems and tickets and I still need help triaging the tickets. James Turnbull has volunteered to help some, but I think we need more than one person. We''ve had a few people step in once or twice, but I''d like to be able to depend on Unreviewed tickets getting handled by someone else, rather

> On 26 Aug 2016, at 03:26, Chris Bieneman <cbieneman at apple.com> wrote: > > I totally did not mean to make the response off list. > Thanks Chris, I'm adding the list to this response. Those interested should see the short discussion quoted below. Adding Chandler explicitly for points raised by Chris below. Thoughts? Cheers -- Dean > >> On Aug 24, 2016, at

Hi all, I was interested in trying out the Xray profiling component in LLVM and was trying to compile a C program with Clang with Xray flags. Unfortunately, I keep getting a linker error everytime I try to compile the C program with Clang. However, the error goes away when I try to compile the same C program with Clang++ with -xc++ flag. Searching around for this issue, looks like somebody has

On Fri, Jun 17, 2016 at 5:42 AM Matthias Braun via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Some of this overlaps with the features in XRay ( > http://lists.llvm.org/pipermail/llvm-dev/2016-April/098901.html). > > Matthias beat me to it! >From reading the RFC, it seems that some of what XRay is doing on the instrumentation side is very similar to what CSI enables. The

Hi Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory

Dear all, I would like to (re-)open a discussion on the following specific question: Assuming we are moving the llvm project to git, should we a) use multiple git repositories, linked together as subrepositories of an umbrella repo, or b) use a single git repository for most llvm subprojects. The current proposal assembled by Renato follows option (a), but I think option (b) will be

Hi, I am trying to build the LLVM suite on a RedHat Enterprise Linux clone (Scientific Linux <https://www.scientificlinux.org/>). In the latest attempt, the build seems to complete without any explicit failures but the `check-all` process fails. Any ideas about what is wrong or suggestions for how to proceed would be much appreciated. This is the current procedure: sudo yum install

Hello I was wondering if someone could put together a bug triage guide and put it on the wiki. I was looking for something to do tonight and z00dax said go hunt some bugs. So I went first to the wiki to look for a guide for a proper procedure on how the team would like bug triaging handled but didn't find one. I have triaged before but i know every place is different. So some guidelines

Hi Kostya, Evgenii, and David, Recently I've been making some incremental changes to the XRay runtime implementation in compiler-rt to reduce the reliance on the C++ standard library components that might have external linkage dependencies. This involves not using containers from the STL and not using non-trivially destructible C++11 thread_local objects. I was wondering whether the

Hi Dean, I have fixed the build failure in r329832. In general, do you think it would be possible to perform the task using higher-level functions available from AddCompilerRT.cmake? They were written exactly to avoid such errors. Regards, George > On Apr 11, 2018, at 10:50 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > Hi Dean, > > For me the build is still

I'm still somewhat unclear about what you mean by "metadata record entry at the beginning of the block". I understand that I can make a MetadataRecord that contains the pid/tid since a metadata record contains 16 bytes. However, I don't understand what do you mean by the "beginning of the block". Do you mean right after the file header? My understanding is that at

We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads. Most of the ideas here were from other people. I *believe* this proposal represents the overall

I'm wondering why the lit tests didn't catch this as part of testing rc1 on ARM. On Thu, Jan 26, 2017 at 11:25 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > XRay is tested automatically on build-bots with tests in LLVM and > compiler-rt . Or are you asking for manual testing instructions? > Of these 2 patches, the compiler-rt patch depends on LLVM patch because

Hi Dean, Wondering if you've seen anything like this: /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/projects/compiler-rt/lib/xray/tests/unit && /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/./bin/clang fdr_logging_test.cc.x86_64.o xray_unit_test_main.cc.x86_64.o gtest-all.cc.x86_64.o -o

Hi llvm-dev, I have unit tests set up in the XRay implementation (compiler-rt/lib/xray/tests/unit) following the pattern that the TSAN and other sanitiser unit tests. However, I'm running into the following problem: When I make changes to the runtime (in this case, XRay) and do `ninja all check-xray`, it seems that the unit tests don't get re-liked to the new version of the runtime. It

> On 4 Oct 2017, at 04:43, Chris Bieneman <beanz at apple.com> wrote: > > I want to make sure I understand the problem so I can try to reproduce it. > > When you say "make changes to the runtime" you mean code in compiler-rt/lib/xray ? > Yes. > Are you using the mono-repo prototype? If not, where do you have compiler-rt's sources (llvm/projects or

On Sat, 3 Jun 2017 16:04:57 -0700 Tim Northover <t.p.northover at gmail.com> wrote: [snip] > I think you should be able to fix it by changing the > compiler-rt/lib/xray/test/CMakeLists.txt. If you find the > "add_compiler_rt_test" call and move "-lstdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt":