search for: release_50

...> We are not planning to use git tags there (at least until the git > migration would happen). Please use the release branches. To me it doesn't matter if it's a tag or a branch, but, as far as I can see, there are no branches for point releases. For example, there's a branch release_50, but no branch for release_501, which exists in the Subversion repository. [1] https://github.com/llvm-mirror/llvm/branches/all -- /Jacob Carlborg

...thy in the last six months, or saw someone else do it, please consider adding it to the release notes. People do read them. If you're responsible for a specific CPU target, please help give those notes some extra love. To add something to the notes, please just commit directly to the branches/release_50 svn branch. Or, just send me an email with some text, and I'll happily do it for you. Many thanks, Hans

...consider adding it to the release notes. >> People do read them. >> >> If you're responsible for a specific CPU target, please help give >> those notes some extra love. >> >> To add something to the notes, please just commit directly to the >> branches/release_50 svn branch. Or, just send me an email with some >> text, and I'll happily do it for you. >> >> Many thanks, >> Hans >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.ll...

...t; People do read them. >>>> >>>> If you're responsible for a specific CPU target, please help give >>>> those notes some extra love. >>>> >>>> To add something to the notes, please just commit directly to the >>>> branches/release_50 svn branch. Or, just send me an email with some >>>> text, and I'll happily do it for you. >>>> >>>> Many thanks, >>>> Hans >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>...

Dear everyone, The release branch was recently created from trunk at r308441 and the trunk version was subsequently incremented to 6.0.0. Release blockers are tracked by https://bugs.llvm.org/show_bug.cgi?id=33849 Please mark any bugs, old or new, that you think need to be fixed before the release as blocking that. Please help out with the release by notifying me of any bugs, commits, or other

...the original repository's subproject. As the original repository will -- by definition -- not touch the other directories, such a conflict can only happen if you have merges between upstream-svn release branches in your history. E.g., if, in your fork of clang.git, you started working from the release_50 branch, then (potentially after a bunch of work), merged the release_60 branch. In your clang fork, you of course had to resolve any conflicts in clang, but would NOT have resolved conflicts between release_50 and release_60 in "llvm" or other subprojects. The tool can't necessarily k...

Hi, Tom, Considering the severity of this bug, I would like to go ahead to push the fix into release_50 branch. The fix has been tested in the trunk and by various people as well and I will also make sure all BPF tests passed before the push. Thanks! Yonghong On Fri, Dec 1, 2017 at 10:18 AM, Y Song <ys114321 at gmail.com> wrote: > Hi, Tom, > > I have a BPF backend bug which is prett...

Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74 https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/lli.cpp#L631 Best, Matt On 11/23/2017 19:49, Stefan Gränitz via llvm-dev wrote: > Maybe the easiest workaround would be overriding symbol resolution for > the function name and redirect it to your own...

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DC...

Hi, I've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom

Hi, I've just tagged 5.0.1-rc3, please test and report the results. Hopefully, this will be the last RC and the final release will be next week. -Tom

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor" ./include/llvm/Executio...

...mov -8(%rax),%rcx // restore rcx push (%rax) // push return address onto the stack sub %rsp,%rax // restore the original value in rax ret END_COMPILERRT_FUNCTION(___chkstk) (source https://github.com/llvm-project/llvm-project-20170507/blob/release_50/compiler-rt/lib/builtins/x86_64/chkstk2.S ) When I replaced it with a simple `ret`, everything worked. The disassembled ntdll implementation is: __chkstk: 1800a9f60: 48 83 ec 10 subq $16, %rsp 1800a9f64: 4c 89 14 24 movq %r10, (%rsp) 1800a9f68: 4c 89 5c 24 08 movq %r11, 8(%r...

I've noticed that there are no tags in any of the Git mirrors [1], [2] or [3]. Would it be possible to add the tags? [1] https://git.llvm.org/git/llvm.git [2] https://github.com/llvm-mirror/llvm [3] https://github.com/llvm-project/llvm-project-20170507 -- /Jacob Carlborg

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

I suspect that there are 2 issues here: * I have incorrect alignment somewhere * MSVC / .pdb / CodeView debugging is not working correctly. I think the latter would help solve the former. I will send out a new email later talking about the issues I'm having debugging llvm-generated binaries with MSVC. On Sat, Sep 30, 2017 at 3:33 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:

Dear testers, 5.0.0-rc2 was just tagged. I know we still have a bunch of open release blockers, but there has been a lot of merged patches and I'd like to find out what the status is. Please build, test and upload binaries to the sftp. When uploading, make sure to use the /data/testers-uploads/ directory on the server. Let me know if there are any issues. I'll upload sources, docs and