search for: branchpoint

...ay. > > We almost certainly want annotated tags. > > > 2. Tags for commits in the master branch that bump the release version. > > > > Most of the discussion about this so far has been on what to put after > > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > > Other things to consider about this tag is that it might be used in > > a git describe alias to identify commits, so it would be helpful if > > it was short. > > > > One idea I had after reading through all the responses was to use the > > -git suffix on th...

...ne > > might check out to get the latest dev version. > > Hmm, I wouldn't worry too much about checking out an old tag by accident... that puts your client into detached head state, and git prints a nice, long warning. (That sort of mistake should be obvious pretty quickly.) v8.0.0-branchpoint might be even clearer, though obviously a little longer. > Whatever the convention we choose, it's going to be painful to change once folks get used to it. (So the wording of the tag is not entirely inconsequential.) My expectation is that the `git describe` aliases will be the typical way...

...propose using tag names like: llvm.org-8.0.0 llvm.org-8.0.0-rc1 Any strong objections to this? 2. Tags for commits in the master branch that bump the release version. Most of the discussion about this so far has been on what to put after the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). Other things to consider about this tag is that it might be used in a git describe alias to identify commits, so it would be helpful if it was short. One idea I had after reading through all the responses was to use the -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear...

On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at google.com> wrote: > > On Thu, Dec 13, 2018, 4:49 AM Hans Wennborg <hans at chromium.org wrote: >> >> On Thu, Dec 13, 2018 at 5:54 AM James Y Knight via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at

On Thu, Mar 09, 2023 at 11:21:23PM +0800, Yangtao Li wrote: > Use i_blockmask() to simplify code. Umm... What's the branchpoint for that series? Not the mainline - there we have i_blocksize() open-coded... > Signed-off-by: Yangtao Li <frank.li at vivo.com> > --- > v3: > -none > v2: > -convert to i_blockmask() > fs/erofs/data.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > &gt...

Hi Al, On 2023/3/10 11:15, Al Viro wrote: > On Thu, Mar 09, 2023 at 11:21:23PM +0800, Yangtao Li wrote: >> Use i_blockmask() to simplify code. > > Umm... What's the branchpoint for that series? Not the mainline - > there we have i_blocksize() open-coded... Actually Yue Hu sent out a clean-up patch and I applied to -next for almost a week and will be upstreamed for 6.3-rc2: https://lore.kernel.org/r/a238dca1-256f-ae2f-4a33-e54861fe4ffb at kernel.org/T/#t And then Ya...

Backtrace: ... 0x00007ffff57fc392 in __assert_fail () from /lib64/libc.so.6 0x00007ffff0cf5bec in nvc0_shader_stage (pipe=<optimized out>) at ./nvc0/nvc0_context.h:204 nvc0_set_constant_buffer (pipe=0x631080, shader=<optimized out>, index=<optimized out>, cb=0x0) at nvc0/nvc0_state.c:771 0x00007ffff0a2cf63 in st_destroy_context (st=0x68a9f0) at state_tracker/st_context.c:382

...o 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019. > > > > Will users of the CMake export files generated by LLVM also need to use 3.15.0 or > is it possibly to have the export files require an older version? > > The 10.0 branchpoint will be in early January, I think it would be better > to wait until after the branch. Mainly because that doesn't give us a > lot of time to actually take advantage of the new features in 3.15.0 before the > branch, so I don't see much benefit in switching over at that date. &gt...

....0 > llvm.org-8.0.0-rc1 > > > Fine. > > > 2. Tags for commits in the master branch that bump the release version. > > Most of the discussion about this so far has been on what to put after > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > Other things to consider about this tag is that it might be used in > a git describe alias to identify commits, so it would be helpful if > it was short. > > One idea I had after reading through all the responses was to use the > -git suffix on the tags. e...

On Fri, Mar 10, 2023 at 11:51:21AM +0800, Yangtao Li wrote: > Hi AI, > > > Umm... What's the branchpoint for that series? > > Not the mainline - there we have i_blocksize() open-coded... > > Sorry, I'm based on the latest branch of the erofs repository. > > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git/log/?h=dev-test > > I think I can resend based on m...

...posal, I propose a cut-over date of December 2, 2019. >> > > >> > >> > Will users of the CMake export files generated by LLVM also need to use 3.15.0 or >> > is it possibly to have the export files require an older version? >> > >> > The 10.0 branchpoint will be in early January, I think it would be better >> > to wait until after the branch. Mainly because that doesn't give us a >> > lot of time to actually take advantage of the new features in 3.15.0 before the >> > branch, so I don't see much benefit in switc...

...> Assuming there are no objections to this proposal, I propose a cut-over > date of December 2, 2019. > > > Will users of the CMake export files generated by LLVM also need to use > 3.15.0 or > is it possibly to have the export files require an older version? > > The 10.0 branchpoint will be in early January, I think it would be better > to wait until after the branch. Mainly because that doesn't give us a > lot of time to actually take advantage of the new features in 3.15.0 > before the > branch, so I don't see much benefit in switching over at that date...

At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers. Historically we've taken into account recent versions of Visual Studio,

James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Fri, Nov 16, 2018 at 5:46 PM David Jones <dlj at google.com> wrote: >> $ 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

...commit/?id=8b7358fe4376aecee0c29ea622f88f9ef07e6b11 (the latest commit on master as of an hour ago or so). After bisection, I discovered that the bug was introduced by https://cgit.freedesktop.org/mesa/mesa/commit/?id=fcbb93e860246375d03f280f927f79d3645a8988 , which is actually *before* the 17.2.x branchpoint. It turns out that this commit was reverted in the 17.2.x branch in commit https://cgit.freedesktop.org/mesa/mesa/commit/?id=17a3e4891bf4fa09785fe9d22db5c79a949004db to fix bug #101983. This was not committed to the 'master' branch, as the fixes in master apparently would have been rather i...

Introduce i_blockmask() to simplify code, which replace (i_blocksize(node) - 1). Like done in commit 93407472a21b("fs: add i_blocksize()"). Signed-off-by: Yangtao Li <frank.li at vivo.com> --- v3: -none v2: -convert to i_blockmask() include/linux/fs.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/fs.h b/include/linux/fs.h index c85916e9f7db..17387d465b8b

...e a cut-over >>> date of December 2, 2019. >>> >>> >>> Will users of the CMake export files generated by LLVM also need to use >>> 3.15.0 or >>> is it possibly to have the export files require an older version? >>> >>> The 10.0 branchpoint will be in early January, I think it would be better >>> to wait until after the branch. Mainly because that doesn't give us a >>> lot of time to actually take advantage of the new features in 3.15.0 >>> before the >>> branch, so I don't see much benefi...

...om/xro8Ixr Trace file: https://drive.google.com/open?id=0B-tTbLKBl-tOdTJxT1o0c2dZMmc The problem is first visible in frame #152, when the second splash screen is displayed. Demo version is available on Steam (needs Wine to run): http://store.steampowered.com/app/43100/ Fedora 22 32-bit Mesa 10.6-branchpoint-773-g1de93f9 Kernel 4.0.6-300.fc22.i686+PAE Xorg 1.17.2 libdrm-2.4.61-3.fc22.i686 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesk...

...s displayed properly. Trace: https://drive.google.com/open?id=0B-tTbLKBl-tOOGEwLXMtdmt2T1U The trace consists of only a single frame which contains >100k calls. Fedora 22 32-bit VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2) (prog-if 00 [VGA controller]) Mesa 10.6-branchpoint-773-g1de93f9 Kernel 4.0.6-300.fc22.i686+PAE Xorg 1.17.2 libdrm-2.4.61-3.fc22.i686 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesk...

https://bugs.freedesktop.org/show_bug.cgi?id=90887 Bug ID: 90887 Summary: PhiMovesPass in register allocator broken Product: Mesa Version: git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at