similar to: [compiler-rt] FreeBSD / MSan support

On 03.03.2018 13:10, David CARLIER via llvm-dev wrote: > Hi dear FreeBSD support, > > The turn of MemorySanitizer to get early support into FreeBSD. > > Kind regards. > I recommend to fix the failures in existing tests. Next enable MSan for sanitizer-common tests and fix the breaking tests on FreeBSD. How about TSan? -------------- next part -------------- A non-text

On 3 Mar 2018, at 13:10, David CARLIER via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi dear FreeBSD support, > > The turn of MemorySanitizer to get early support into FreeBSD. Thanks David, what are your plans? Sorry for slacking off on your other sanitizer reviews for FreeBSD. I have been busy on too many other things. :( -Dimitry -------------- next part

I'm sorry, but I don't think LLDB has any release notes. On Sat, Aug 26, 2017 at 9:49 PM, Kamil Rytarowski <n54 at gmx.com> wrote: > LLDB: > > Switched the NetBSD platform to new remote tracing capable framework. > > Preliminary support for tracing NetBSD(/amd64) processes and core files > with a single thread. > > On 25.08.2017 02:44, Hans Wennborg via

Dear everyone, The release schedule has snuck up on me again, and it's time to wrap up the release. We won't make it to the final tag on the 21st as per the schedule, but I would like to get all outstanding blockers fixed and rc3 tagged by Friday. Hopefully this would be the last rc and we could go to final soon after. If you're involved in a release-blocking bug (see

On 19.02.2018 16:57, Hans Wennborg via lldb-dev wrote: > I would also like to get the release notes ready this week. If you've > been meaning to write something but didn't get around to it yet, now > is the time. > Notes regarding the X86(_64) backend: Preliminary support for Sanitizers and sibling features on NetBSD (ASan, UBsan, TSan, MSan, SafeStack, libFuzzer). Feel free

Hello everybody, I've run into some strange behavior with memory sanitizer that I can't explain and hope somebody with more knowledge of the implementation would be able to help me out or at least point me into the right direction. For background, I'm using memory sanitizer to check Julia (julialang.org), which uses (or at least will once I track down a few bugs) MCJIT for the code

I'm seeing some test failures for unit tests for msan (check-msan) happening in googletest, which I find weird. I'm on Arch Linux, with r342711. Below is one type of error that I see. The full log is 416MB (!) big. My guess is that those errors are related, but if anyone needs the full log, I'll provide it. Here is a reduced log from the end:

I assume there are transitions between JITted code and native helper functions. How are you handling them? Are native functions MSan-instrumented? MSan is passing shadow across function calls in TLS slots. Does your TLS implementation guarantee that accesses to __msan_param_tls from JITted and from native code map to the same memory? On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

Hello testers, 4.0.0-rc3 was just tagged from the branch at r296762. This is a release candidate in the real sense: if no major issues show up with this one, it is the version that will be released. Please let me know if you find any issues, including in release notes or documentation, which will be on the pre-release web site later today. Please build, test, and upload binaries to the sftp

On Friday, July 31, 2015 07:50 AM, Hans Wennborg wrote: > Dear testers, > > 3.7.0-rc2 was just tagged. Please test, build binaries, upload to the > sftp, and report results to this thread. LNT is looking good on Ubuntu 14.04 x64, uploaded: clang+llvm-3.7.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz The errors reported during build are: Failing Tests (17):

On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via Release-testers wrote: > Dear testers, > > Release Candidate 3 has just been tagged [1]. Please build, test, and > upload to the sftp. Uploaded: clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10.tar.xz clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz On

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) Native: All ok Cross compiling to MIPS: All ok clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I've done some amount of triaging what some critical elements of the failures are. Unabridged log is attached. Failing Tests (94): LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool LLVM-Unit ::

Dear testers, 3.7.0-rc1 was just tagged; please start your testing engines :-) Upload binaries to the sftp and report your results to this thread. I'm sorry for the delay between branching and tagging. The changes to the release script took a little longer than I hoped. Thanks for helping with the release, and do let me know of any issues, questions, etc. The tracking bug for release

Dear testers, 3.7.0-rc2 was just tagged. Please test, build binaries, upload to the sftp, and report results to this thread. A lot of fixes have been applied since rc1, both to the build script and the code in general, so hopefully it will be less bumpy this time. >From this point, I will no longer accept merge requests to finish existing features; it's now bug-fixes only. Thanks again

Dear testers, 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: - r245902: Revert r245355: change of clang-tools-extra symlink in the release script - r245947: Merge of r245927: Fix LLDB build on MIPS - r245948: Deprecate the DataLayout on the TargetMachine, and backport the 3.8 API - Changes to the ReleaseNotes. Those changes should all be safe, and I expect this to be an extremely