search for: release_70

...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 probably automatically detect it and set the local branch up to track it. > but I don't see a v7.0.0 specific tag or branch - is it the 'prerelease_20180108' tag? There won't be any 7.0.0 tags yet because we d...

...GIT command-line interface to select to the exact same set of sources used for the v7.0.0 branch, Do you mean the commit that was forked to create the 7.0 branch, the commit that was released as 7.0.0, or the current status of the 7.0 branch? In turn they'd be: 1. git merge-base master origin/release_70 2. These are stored as tags I believe, though the format has changed and we only started recently. "git tag" lists what we have now, with an obvious mapping to releases (for a human). 3. Just plain origin/release_70 > or for the sources at a particular SVN revision (e.g. r338536)? Fo...

On Fri, Aug 3, 2018 at 3:38 PM, <paul.robinson at sony.com> wrote: > Hi Hans, > > I was just trying to push a release note about DWARF v5 support. I did: > git checkout release_70 # in the monorepo > git commit <update to llvm/docs/ReleaseNotes.rst> > git llvm push > but that fails. How do you want to do release notes? I'm not familiar with "git llvm", but I suspect it doesn't work for release branches. Can you just svn commit it instea...

Hi, The release_70 branch is ready for the 7.1.0 release. I have updated the version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, which is the only bug we will be fixing in this release. Since this is an ABI breaking changing and also we are introducing a minor version for the first time, pleas...

On 02/05/2019 08:07 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > wrote: >> Hi, >> >> The release_70 branch is ready for the 7.1.0 release. I have updated the >> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >> which is the only bug we will be fixing in this release. >> >> Since this is an ABI breaking changing and also we are introducing a >...

...26 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >> On 02/05/2019 08:07 AM, Michał Górny wrote: >>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers >>> wrote: >>>> Hi, >>>> >>>> The release_70 branch is ready for the 7.1.0 release. I have updated the >>>> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >>>> which is the only bug we will be fixing in this release. >>>> >>>> Since this is an ABI breaking changing an...

...between LLVM 9.0.1 Release and LLVM 9.0.1-rc1 Release, ``` # md5sum and tarball name 15f234da3e9a7f2a50173c1c95a6436e compiler-rt-9.0.1rc1.src.tar.xz 1b39b9b90007a2170ebe77d6214ec581 compiler-rt-9.0.1.src.tar.xz ``` Does these tarball all from branch release_90(there are also branch release_80, release_70, etc)? If so, which commit was picked by the different llvm release? Thanks, Hu Keping -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200415/8144ceaa/attachment.html>

...lard wrote: > > > > On 02/05/2019 08:07 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > The release_70 branch is ready for the 7.1.0 release. I have updated the > > > > > > version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, > > > > > > which is the only bug we will be fixing in this release. > > > > > > > > > &gt...

...7 AM, Michał Górny wrote: > > > > > > > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > The release_70 branch is ready for the 7.1.0 release. I have updated the > > > > > > > > version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, > > > > > > > > which is the only bug we will be fixing in this release. > > > > > >...

Hi, Fixing http://llvm.org/PR39427 in the release_70 branch, will change the ABI of a clang built libLLVM-7.so so that it is no longer compatible with the 7.0.0 release. libLLVM-7.so built by gcc will not be affected by this fix. Changing the ABI is something we aren't supposed to do in stable releases, but this fixes an ABI difference between...

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

Dear testers, The final version of 7.0.0 has been tagged from the branch at r342370. It is identical to rc3 modulo release notes and docs changes. Please build the final binaries and upload to the sftp. For those following along: this means 7.0.0 is done, but it will take a few days to get all the tarballs ready and published on the web page. I will send the announcement once everything is

...an a annotated tag on master? (This seems less trivial, but my reasoning is below.) The overall goal is for `git describe` to give a reasonable default output. Reasoning for request #1: Example: add a tag after the cut point of the 7.0 release: $ git log --oneline $(git merge-base HEAD origin/release_70)..HEAD | tail -1 63297479398 Bump the trunk version to 8.0.0svn $ git tag -m 'Begin development of 8.0.0.' '8.0.0svn' 63297479398 Then, `git describe` can give a useful result that would be stable(-ish [*]): $ git describe --match=\*svn 8.0.0svn-7878-gfdb08034fd8 ([*] Subject to...

Possibly unrelated but since someone asked, I wonder why we don’t have monorepo for releases? For example a .tar.s containing all LLVM6.0 components placed at correct location Zhang > 在 2018年8月30日，18:16，Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > Thanks! >> On Thu, Aug 30, 2018 at 7:31 PM NAKAMURA Takumi <geek4civic at gmail.com> wrote:

Hi everyone, The release branch for 7.0.0 was created off trunk at r338536 earlier today, and the trunk version was subsequently bumped to 8.0.0. Release blockers are tracked by https://llvm.org/PR38406 Please mark any bugs, old or new, that need to be fixed for the release as blocking that. To get a change committed to the branch, first commit it to trunk as usual, and then request it to be

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) x64 Native Tools Command Prompt for VS 2017 directory structure: test     llvm <-- git clone https://github.com/llvm-mirror/llvm, git checkout release_70       tools         clang <-- git clone https://github.com/llvm-mirror/clang, git checkout release_70     llvm_build build steps: cd llvm_build cmake -Thost=x64 -G "Visual Studio 15 2017 Win64" -DLLVM_TARGETS_TO_BUILD=host -DLLVM_BUILD_EXAMPLES=1 -DCLANG_BUILD_EXAMPLES=1 -DLLVM_IN...

...uot; } attributes #1 = { norecurse nounwind readnone } attributes #2 = { norecurse noreturn nounwind readnone } !llvm.module.flags = !{!0, !1} !llvm.ident = !{!2} !0 = !{i32 1, !"wchar_size", i32 4} !1 = !{i32 7, !"PIC Level", i32 2} !2 = !{!"clang version 7.0.1 (branches/release_70 348238)"}

Hi Hans, > The final version of 7.0.0 has been tagged from the branch at r342370. I'd like to fork from 7.0.0 final but I got confused: The tip of release_70 branch is still r341805, which is identical to rc3. This should be r342370 instead, shouldn't it? Or the final (r342370) does not go into the release branch? Or it just takes some more time? Thanks, Gabor On Mon, Sep 17, 2018 at 1:42 PM Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org&g...

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

...I know) >> pair of requests that have only recently solidified for me. >> >> 1. Could you add annotated tags after the cut point of each release? (I >> think this would probably be easy.) >> > > I suppose the monorepo has annotated tags. > > $ git describe RELEASE_701/rc1^ > RELEASE_700/final-20-gd0540f76dd4f > > $ git show RELEASE_700/final > tag RELEASE_700/final > Tagger: Hans Wennborg <hans at hanshq.net> > Date: Mon Sep 17 20:38:10 2018 > > Creating release candidate final from release_700 branch > > ...Are they not wh...