similar to: 'git llvm push' other branches?

Hi there, Do we have any plan to add release tags to the compiler-rt git repo, say http://llvm.org/git/compiler-rt ? Without a release tag I’m not sure which version of compiler-rt the llvm-project is using. Take “LLVM 10.0.0 Release”( https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0) as an example: The tarball of compiler-rt been used in this version is

After the extended discussion I think it's in a pretty good shape now: https://reviews.llvm.org/D61550 Any further comments? > On 4. May 2019, at 11:32, Alex Denisov <1101.debian at gmail.com> wrote: > > The final draft is now published and awaiting your comments or approval :) > > https://reviews.llvm.org/D61550 > >> On 15. Apr 2019, at 16:01, Alex Denisov

Hi folks, At EuroLLVM we had a round table for organizers of LLVM Socials around the globe. After the discussion we decided to get some sort of guidelines for those who want to organize the meetup in their city, but have any questions and don't know where to start. Currently, I am creating the very first draft. Once it's in a good shape I will send it to the phabricator. I am looking

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote: >

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute the constructors straight away, rather than naming them and looking them up

> On Nov 15, 2019, at 1:52 AM, Alex Denisov <1101.debian at gmail.com> wrote: > >> I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. > > IIRC, the -p option of 'patch' is exactly for doing this. Would that simplify your use-case? > Yes, for a single patch that would work. If there is a way to do

Dear testers, 8.0.0-rc2 has been tagged from the release_80 branch at r353413. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

On Fri, Feb 8, 2019 at 9:53 AM Paweł Sikora via cfe-dev < cfe-dev at lists.llvm.org> wrote: > ----- Oryginalna wiadomość ----- > > Dear testers, > > > > 8.0.0-rc2 has been tagged from the release_80 branch at r353413. > > Hi, > > i've noticed a compile error with rc2 and libc++ (release_80 @svn). looks > similar to

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

Dear testers, 8.0.0-rc5 was just tagged from the release_80 branch at r355909. This is identical to rc4 with the addition of r355743. Hopefully it is the final release candidate, so please give it a good testing. As usual, please run the test script, share your results, and upload binaries. I'll publish source tarballs and docs as soon as possible, and binaries as they become available.

On Alex's advice I am switching from MCJIT to the Orc API to compile and execute functions. Starting from the new clang-interpreter example in the source code (top of the tree!), I am able to execute my functions all right... as long as there are no constructors and destructors to call. My question: is there a simple way, with the Orc API, to run a module's constructors and destructors? I

On 31 May 2018 at 08:41, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I understand the linking problem. What I do not understand is how to debug the difference between two versions of compilers. > This what I do (briefly): > > clang++-4 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib > > clang++-5 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib If you add -v then Clang will

Dear testers, 8.0.0-rc3 was just tagged from the release_80 branch at r355015. We're running a little behind schedule now, but I think we're also close to be able to call this done. Please take a close look at this release candidate. Unless anything bad comes up, this is probably very similar to what the final release will look like. Testers, please run the test script, share your

> On 3 Apr 2017, at 22:47, Alex Denisov <1101.debian at gmail.com> wrote: > > The HTML generated using sphinx[1]. > At the bottom of each page you can see actual version of sphinx used to generate this page. > Thanks -- interesting that the docs haven't been updated since March 15th: © Copyright 2003-2017, LLVM Project. Last updated on 2017-03-16. Created using Sphinx

Dear testers, The final version of 8.0.0 was just tagged from the release_80 branch at r356364. It's identical to rc5 except for a few documentation changes. Apologies for being behind schedule. It took longer than planned this time. Please build the final binaries and upload to the sftp. For those following along: this means 8.0.0 is done, but it will take a few days to get all the

On Thu, 24 Jan 2019, Hans Wennborg wrote: > On Thu, Jan 24, 2019 at 3:51 AM Martin Storsjö <martin at martin.st> wrote: >> >> FWIW, I've got the main COFF functionality that I had planned on doing >> committed in trunk by now. So at least for my own usecases, it's fully >> functional by now. (And for unsupported options, it clearly errors out.) >>

Hello everyone, The release branch for LLVM 9 and its sub-projects was just created from trunk at r366426, and the trunk version was subsequently bumped to 10.0.0. Release blockers are tracked by https://llvm.org/PR42474 Please mark any bugs, old or new, that need to be fixed before the release as blocking that. To get a change committed to the branch, first commit it to trunk as usual, and

> I’ve seen the same problem, but didn’t find solution back then. > I can give a hint that it is related to a thread local storage (notice TLS in the name). > > The same result can be reproduced by this simple program: > > thread_local int x = 0; > int main() { > return 0; > } > >When compiled into IR it produces similar error: > >LLVM ERROR:

2018-06-01 2:06 GMT-05:00 Alex Denisov <1101.debian at gmail.com>: > If there are any other hints: send them my way :) Debug with gdb, but a breakpoint at https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Utils/SymbolRewriter.cpp#L91. It should hit twice (which is the error reported). At each break you can look at where the machine code is coming from (e.g. a shared object),

Hello everyone, 9.0.0-rc6 was just tagged from the release_90 branch at r372100. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc6. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc6 This is the same as rc5 plus one very minor change (r371969) that still seemed good to pick up. I'm not allocating extra time for testing this one, expecting to tag