similar to: llvm 3.8.1 Release

OK, so, if I understand, the tag is at 3.8.1, but there is no source drop available for download? Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, July 5, 2016 4:12 PM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] llvm 3.8.1 Release Hi Del, Yes, the tag is for the latest stable release. It's

We just wanted to check to see if they are real bugs first. We will report them if they are not already fixed. Thanks. Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Wednesday, July 6, 2016 12:07 AM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] llvm 3.8.1 Release Did you report the bugs? It would be a

Hello Tom, Tom Stellard via llvm-dev <llvm-dev <at> lists.llvm.org> writes: > > Hi, > > I'm working on uploading all the packages now. I've downloaded them files several times from different locations (suspected my webgw might muck with the content) using different clients and the result is the same: $ gpg --verify ~/Downloads/cfe-3.8.1.src.tar.xz.sig

> Test suite is green but I'm seeing two libc++ test failures when running check-all. What tests are failing? On Fri, Jun 10, 2016 at 5:13 PM, Nikola Smiljanic via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Uploaded Fedora and openSUSE binaries. Test suite is green but I'm seeing > two libc++ test failures when running check-all. I'm pretty sure these were >

Hi, I had a quick look at that link and it seems to be a linker internal error. Presumably we're triggering a bug in the system toolchain. FWIW, my mipsel build on a Debian Jessie machine (binutils 2.24.90.20141023-1) successfully completed test-release.sh. I'm currently running the tests. Here's the relevant bit of the log from your link: cd

Hi, I've tagged 3.8.1-final, so testers can start building the final binaries. -Tom

Hi, I've tagged 3.8.1-rc1, testers can begin testing. -Tom

Hi, It's about time to start thinking about the 3.8.1 release. Here is a proposed release schedule: May 25 - Deadline to request a change be merged to the 3.8 branch. June 1 - Deadline to merge changes to the 3.8 branch. June 1 - 3.8.1-rc1 June 8 - 3.8.1-rc2 (if necessary) June 15 - 3.8.1 Release If you want a patch included in the 3.8.1 release, send an email to llvm-commits with the

We have been using LLVM 3.4 and are currently migrating to LLVM 3.8.1. We have been using the Old JIT and since it has been removed since 3.6, we have to use MCJIT. I find that run-time performance is very poor in 3.8.1 for the Fibonacci example in llvm/examples/fibonacci.cpp. Logs below for fib34 and fib381 for input values of 30 and 40. I first thought it could be that MCJIT compile time is

Hello, The llvm.org web site says the release would be in mid-june. There was a message posted to the dev list that 3.8.1 was tagged. Then there was another message that said essentially "don't make your own tarballs - wait for release tarballs". I have two questions: 1. If the 3.8.1 tag does not represent what will be the tarball contents, will the tag be moved when the

LLVM 3.8.1 is now available! Download it now, or read the release notes. This release contains bug-fixes for the LLVM 3.8.0 release. This release is API and ABI compatible with 3.8.0. LLVM 3.8.1 would not be possible without the help of our volunteer release team! Thanks to all the release testers: Hans Wennborg, Diana Picus, Brian Cain, Sylvestre Ledru, Daniel Sanders, Nikola Smiljanic, Ben

The source tarball for clang-tools-extra-3.9.0.src.tar.xz is also missing as well from http://llvm.org/releases/3.8.1/. Jack On Tue, Jul 12, 2016 at 7:34 AM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > There is no compiler-rt v3.8.1 source tarball available on > <http://llvm.org/releases/3.8.1/>. > > - Sedat - > > On Mon, Jun 27, 2016 at

On 23 June 2016 at 10:56, Bernhard Rosenkränzer <llvm-dev at lists.llvm.org> wrote: > This caused our tarball generation scripts to mess up and name the tarballs > 3.8.0 -- I've fixed the script to look at CMakeLists.txt instead and now (so > far) all is good, but while configure is still there it should probably > reflect the version info correctly. Hi Bero, If anything,

Please have a look at the dedicated mailing list: http://lists.llvm.org/pipermail/llvm-branch-commits/ Please wait for the official release to happen, you will then find tarballs on llvm.org. They will also contain correct version strings, though I haven't yet tried building from the SVN branches directly. Maybe you need to use the SVN tags, $ clang --version currently gives me "clang

On 26 June 2016 at 13:31, Anton Korobeynikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What you're probably missing is that 3.8.1 is made in release_38 > branch. So, everything is there and already mirrored. > > Source tarballs will be available upon the release. Which are just coming, now that final has been tested successfully. :) They'll be announced in the

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

On Sun, Jun 26, 2016 at 2:48 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 26 June 2016 at 13:31, Anton Korobeynikov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> What you're probably missing is that 3.8.1 is made in release_38 >> branch. So, everything is there and already mirrored. >> >> Source tarballs will be available upon the

On Mon, Jun 27, 2016 at 9:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >>>> What you're probably missing is that 3.8.1 is made in release_38 >>>> branch. So, everything is there and already mirrored. >>>> >>>> Source tarballs will be available upon the release. >>> Which are just coming, now that final has been

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

Hi, I want to use a function defined in c(++)-code from code generated by llvm. For this I use ExecutionEngine.addGlobalMapping(). I started with the JIT execution engine and everything worked, then I switched to the interpreter engine and it stopped working, but only if compiled on a Linux system. More precisely it works if I use llvm 3.8.1 + gcc (Linux) + JIT llvm 3.8.0 + mingw-gcc