similar to: [4.0.0 Release] The branch is here, the release process starts

It's there for me now: $ git fetch origin remote: Counting objects: 811, done. remote: Compressing objects: 100% (561/561), done. remote: Total 562 (delta 462), reused 2 (delta 0) Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done. Resolving deltas: 100% (462/462), completed with 240 local objects. >From http://llvm.org/git/llvm 233ecbde652..16c5e12d3a5 master ->

That's odd... Have the branch created as usual? On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg <hans at chromium.org> wrote: > Oh wait, the branch on the git mirror doesn't look right! > > Anton, can you take a look? The first commit on the branch for llvm is: > > ------------------------------------------------------------------------ > r291843 | hans | 2017-01-12

Very cool initiative! Thank you! On Fri, Jan 20, 2017, at 10:59 AM, Mehdi Amini via cfe-dev wrote: > Hi, > > FYI, I added a Green dragon job to build and test (stage 1 only right > now) the release branch: > http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/ > <http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/> > > — >

> Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. I have encountered very long compile times for three large source files containing generated/unrolled code at -O1. We are talking about 10+ hours here without completing, so it looks very much like an endless loop. The

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

Hi, I'm trying to do a build and install on Windows 10 with Visual Studio 2015 Community Edition for the X86 and ARM targets, from the current release_40 branch. While compilation completes without error, the INSTALL target fails with the following error: 54> CMake Error at projects/compiler-rt/lib/builtins/cmake_install.cmake:34 (file): 54> file INSTALL cannot find 54>

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

Hi, I wanted to know if it was possible to force ARM backend to compile a function in ARM while the rest is in Thumb mode. I tried the attributes which is used in GCC but it doesn't work. Here is what I tried: https://pastebin.com/jCr5LPUY Thanks in advance, Uvekilledkenny -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Hi Rui, The motivation would be primarily that LLVM/Clang/LLD are community projects such that if I or someone in the community added support for e.g. symbol aliases, then it could be reviewed and potentially merged. ld64 on the other hand does not have a community process for patch submission and code review that I am aware of so its unlikely that if someone from the community came up with a

It is my pleasure to announce that LLVM 4 is now available. Get it here: http://llvm.org/releases/download.html#4.0.0 LLVM is now using a new versioning scheme, increasing the major version number with each major release. Stable updates to this release will be versioned 4.0.x, and the next major release, six months from now, will be version 5.0.0. For more information, see

It is my pleasure to announce that LLVM 4 is now available. Get it here: http://llvm.org/releases/download.html#4.0.0 LLVM is now using a new versioning scheme, increasing the major version number with each major release. Stable updates to this release will be versioned 4.0.x, and the next major release, six months from now, will be version 5.0.0. For more information, see

Hi Martin, On Fri, 3 Aug 2018 at 14:10, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > $ git branch --list > * master > martino By default "git branch" only lists local branches. "git branch -a" will list all of them, including (for me) "remotes/origin/release_70". If you just type "git checkout release_70" git will

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

from https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Under certain circumstances, GCC may duplicate (or remove duplicates of) > your assembly code when optimizing. This can lead to unexpected duplicate > symbol errors during compilation if your asm code defines symbols or > labels. Using ‘%=’ (see AssemblerTemplate) may help resolve this problem. ‘%=’ > Outputs a number that is

Hello, Context: I have been packaging the llvm toolchain for Debian & Ubuntu and also providing these packages on https://apt.llvm.org/. One of the goal is to have different versions co-installable. For that, I am renaming the binaries and libraries. Now, as we are not using the minor version (the Y in X.Y.Z), there isn't much point in calling our tools foo-7.0 as we won't create a

On 17 Mar 2018, at 14:48, Sylvestre Ledru via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Context: I have been packaging the llvm toolchain for Debian & Ubuntu > and also providing these packages on https://apt.llvm.org/. > One of the goal is to have different versions co-installable. For that, > I am renaming the binaries and libraries. > > Now, as we are not