similar to: (no subject)

On Fri, Nov 02, 2012 at 06:45:07PM +0400, Alexey Samsonov wrote: > Hi, Jack! > > > I'll take a look at this. However, tests below fail for a different reason > (they don't use Debug/AsanTest at all). > How do you configure a CMake build tree? Can you somehow get (or run > manually) the script which is used > for running log-path_test.cc and other failing test

Hi, Jack! On Fri, Nov 2, 2012 at 6:18 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Have you noticed that llvm/clang svn produces the following linker > warnings on > 'make check-all'? > > Linking CXX executable Debug/AsanTest > ld: warning: direct access in > llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak >

Nick, Have you noticed that llvm/clang svn produces the following linker warnings on 'make check-all'? Linking CXX executable Debug/AsanTest ld: warning: direct access in llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak symbol vtable for llvm::convertible_fwd_ostream means the weak symbol cannot be overridden at runtime. This was likely caused by different

Hi David, Vedant, It looks like we might have UB somewhere connected with reading coverage mapping serialized in v2 format (with compressed function names). I committed my patch, r266436, using the current format for .covmapping file, and then buildbots complained about it: * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11935/steps/check-llvm%20ubsan/logs/stdio *

After a few attempts I think we’re in sight of success: we only have the two following bots remaining with old versions of libstdc++ and new versions of clang: polly-amd64-linux polly-arm-linux Once fixed the toolchain bump should stick. > On Jan 31, 2019, at 2:07 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Jan 31, 2019, at 2:03 PM,

On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in

Hello list, yesterday I finished work having my whole dialplan available... Today I want to make a call from one local phone to another and I get this : [Aug 28 10:48:57] NOTICE[1895]: chan_sip.c:15144 handle_request_invite: Call from 'test2' to extension '60' rejected because extension not found. Although I have this context : [from-TEST] where all my local extensions are

Hi! UBSan bootstrap bot fails with error report on 5 llvm-cov and llvm-profdata lit-tests: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/4526/steps/check-llvm%20ubsan/logs/stdio Also see http://llvm.org/bugs/show_bug.cgi?id=20815. The error reports look vaild: in general it's incorrect to load uint64_t, or even structures like "RawHeader" or

Hi, The 6.0.1-rc2 release has been tagged. Testers may begin testing and reporting results. -Tom

Hi, I've just tagged the 6.0.1-rc1 release. Testers may begin testing and uploading binaries. Also, any tester who has not tested 5.0.2-rc1 and would like to do so please try to do this before Friday, because I would like to tag 5.0.2-final then. As a reminder to users and developers, May 18 is the deadline for submitting merge requests for 6.0.1, so there is still time to get bug fixes

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

after install libguestfs_xfs, all results are: [using guestfish] guestfish -N fs:xfs -m /dev/sda1 statvfs / bsize: 4096 frsize: 4096 blocks: 24713 bfree: 23391 bavail: 23391 files: 51136 ffree: 51133 favail: 51133 fsid: 2049 flag: 4096 namemax: 255 [using virt-rescure] virt-rescue -a test1.img ><rescue> mount /dev/sda1 /sysroot ><rescue> stat -f /sysroot File:

Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at the moment. I’m inclined to leave it checked in, and try to get it into the LLVM 8 branch as well. > On Feb 7, 2019, at 9:18 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not

> On 9 Feb 2018, at 10:20, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >>> >>> There's been a lot of merges since rc1, and hopefully the tests are in

Hello, Can someone recommend me where is best place to find Asterisk Expert/Consultant for freelance work? If you are interested to work as a freelancer, you can email me directly. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150902/5a99cbfe/attachment.html>

The bot has been failing its CMake step for a while now. Probably fallout from renaming Msf to MSF. Can somebody get this straightened out? It's one of the bots that run VS2013 AFAICT which makes it useful to me. Thanks, --paulr

Dear all, For my thesis, I've been working on automatic inference of state machines for SSH servers. I ran into a couple of particularities regarding OpenSSH's inferred state machine, and was hoping some of you might be interested. Maybe you can even shed some light on it. Setup: I'm using LearnLib's (Java) version of the L* learning algorithm [1] to come up with sequences of

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>

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

Hi, (Reposting the request to llvm-dev for better visibility) I had to revert a change today, due to test errors on some buildbots. The errors did seem to only happen on the ppc64be and aarch64 buildbots. I don't have access to a ppc64be setup to test on, but I've tried to build and run in a setup very similar to the one on the aarch64 buildbot, but I can't reproduce the errors