[lldb-dev] [Bug 46014] New: inconsistent behaviors for calling function va_arg() at -O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=46014
Bug ID: 46014
Summary: inconsistent behaviors for calling function va_arg()
at -O3 (-O0 is correct)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ cat small.c
#include
void f(int i, ...) {
int j;
double d;
char *s;
va_list ap;
va_start(ap, i);
j = va_arg(ap, int);
d = va_arg(ap, double);
s = va_arg(ap, char *);
va_end(ap);
}
int main() {
f(1);
return 0;
}
$ clang -g -O3 small.c; lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:16:3, address =
0x004011e1
(lldb) r
Process 139129 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 139129 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004011e1 a.out`main at small.c:16:3
13 }
14
15 int main() {
-> 16 f(1);
17 return 0;
18 }
(lldb) si -c 26
Process 139129 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x004011c7 a.out`f(i=) at small.c:11:7
8 va_start(ap, i);
9 j = va_arg(ap, int);
10 d = va_arg(ap, double);
-> 11 s = va_arg(ap, char *);
12 va_end(ap);
13 }
14
(lldb)
/**
As showed above, Line 11 is hit by lldb when using "instruction level" step.
However, Line 11 is not hit by lldb when setting breakpoint on it as follow:
**/
$ clang -g -O3 small.c; lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 11
Breakpoint 1: where = a.out`f + 142 at small.c:11:7, address =
0x0040119e
(lldb) r
Process 138683 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 138683 exited with status = 0 (0x)
(lldb)
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Release process changes
All of this sounds reasonable to me, but we don't directly follow the upstream release cadence so I'm an interested observer at most. Philip On 5/21/20 11:59 AM, Tom Stellard via llvm-dev wrote: Hi, I would like to propose a few changes to the LLVM release process. The current process is documented here: https://llvm.org/docs/HowToReleaseLLVM.html There are two parts to this proposal. The first is a list of clarifications, which are things we are currently doing that aren't documented. The second is a list of changes which would actually modify how releases are currently managed. *** Proposed Clarifications *** ** Release manager is allowed to commit changes to the release branch without code owner approval. However, the release manager is encouraged to consult with code owners or patch reviewers for non-trivial changes. It's not practical to get code owner approval every time. Either because there is no code owner or because the number of backports is too high (e.g. pre-rc1 / pre-rc2). This proposed clarification matches how releases are currently managed. ** There is no official release criteria. We have time-based releases and when the release is 'ready' has been up to the discretion of the release manager. Changing the release criteria is out of the scope of this proposal, but I do think it would be good to have a discussion about this as a community, so I'm going to start a separate thread to discuss this. *** Proposed Changes *** ** Create a time-based bug-fix release schedule. After each major release, make a new bug-fix release every 2 weeks for 12 weeks (6 releases total). ** Eliminate release candidates for bug-fix releases. The current unofficial bug-fix release schedule is: X.Y.1-rc1 (6 weeks after major release) X.Y.1-rc2 (10 weeks after major release) X.Y.1-final (12 weeks after major release) I think this change will improve the overall test coverage of the release branch. I don't think the branch itself or even the release candidates get the same level of testing as the final releases. If we are consistently snapshotting the release branch and putting out releases, I think this will make it easier and thus more likely that users will test out the release branch code. Additionally, with more frequent bug-fix release it removes the need to have release candidate releases. Every bug-fix release (up until the last one) would serve the same purpose as our current release candidates in that they are intended to give users an easier way to test the code before the final release. ** Create clear rules for what kind of backports are accepted during each release phase. * Before RC1:Patches should be limited to bug fixes, important optimization improvements, or completion of features that were started before the branch was created. As with all phases, release managers and code owners can reject patches that are deemed too invasive. * Before RC2: Patches should be limited to bug fixes or backend specific improvements that are determined to be very safe. * Before RC3/Final: Major Release* Patches should be limited to critical bugs or regressions. * Bug fix releases: Patches should be limited to bug fixes or very safe and critical performance improvements. Patches must maintain both API and ABI compatibility with the previous major release. * Final bug fix release: Patches should be limited to critical bug fixes only. What does everyone thing about these changes? -Tom ___ LLVM Developers mailing list llvm-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Release process changes
On 21 May 2020, at 14:59, Tom Stellard via llvm-dev wrote: Hi, I would like to propose a few changes to the LLVM release process. The current process is documented here: https://llvm.org/docs/HowToReleaseLLVM.html There are two parts to this proposal. The first is a list of clarifications, which are things we are currently doing that aren't documented. The second is a list of changes which would actually modify how releases are currently managed. *** Proposed Clarifications *** ** Release manager is allowed to commit changes to the release branch without code owner approval. However, the release manager is encouraged to consult with code owners or patch reviewers for non-trivial changes. It's not practical to get code owner approval every time. Either because there is no code owner or because the number of backports is too high (e.g. pre-rc1 / pre-rc2). This proposed clarification matches how releases are currently managed. If this is how things are currently managed, it’s hard to argue against it, but I do think that — independently — we should make a stronger effort to ensure that we have active code owners covering the entire codebase. My sense is that the ownership problem is deepest in two specific parts of the project: compiler-rt and LLVM itself. Do you agree? John. ** There is no official release criteria. We have time-based releases and when the release is 'ready' has been up to the discretion of the release manager. Changing the release criteria is out of the scope of this proposal, but I do think it would be good to have a discussion about this as a community, so I'm going to start a separate thread to discuss this. *** Proposed Changes *** ** Create a time-based bug-fix release schedule. After each major release, make a new bug-fix release every 2 weeks for 12 weeks (6 releases total). ** Eliminate release candidates for bug-fix releases. The current unofficial bug-fix release schedule is: X.Y.1-rc1 (6 weeks after major release) X.Y.1-rc2 (10 weeks after major release) X.Y.1-final (12 weeks after major release) I think this change will improve the overall test coverage of the release branch. I don't think the branch itself or even the release candidates get the same level of testing as the final releases. If we are consistently snapshotting the release branch and putting out releases, I think this will make it easier and thus more likely that users will test out the release branch code. Additionally, with more frequent bug-fix release it removes the need to have release candidate releases. Every bug-fix release (up until the last one) would serve the same purpose as our current release candidates in that they are intended to give users an easier way to test the code before the final release. ** Create clear rules for what kind of backports are accepted during each release phase. * Before RC1:Patches should be limited to bug fixes, important optimization improvements, or completion of features that were started before the branch was created. As with all phases, release managers and code owners can reject patches that are deemed too invasive. * Before RC2: Patches should be limited to bug fixes or backend specific improvements that are determined to be very safe. * Before RC3/Final: Major Release* Patches should be limited to critical bugs or regressions. * Bug fix releases: Patches should be limited to bug fixes or very safe and critical performance improvements. Patches must maintain both API and ABI compatibility with the previous major release. * Final bug fix release: Patches should be limited to critical bug fixes only. What does everyone thing about these changes? -Tom ___ LLVM Developers mailing list llvm-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Release-testers] RFC: Release process changes
On 2020-05-21, Michał Górny via cfe-dev wrote: >On Thu, 2020-05-21 at 11:59 -0700, Tom Stellard via Release-testers >wrote: >> Hi, >> >> I would like to propose a few changes to the LLVM release process. The >> current process is documented here: >> https://llvm.org/docs/HowToReleaseLLVM.html >> >> There are two parts to this proposal. The first is a list of clarifications, >> which are things we are currently doing that aren't documented. The second >> is a list of changes which would actually modify how releases are currently >> managed. >> >> >> >> *** Proposed Clarifications *** >> >> >> >> ** Release manager is allowed to commit changes to the release branch >> without >> code owner approval. However, the release manager is encouraged to >> consult >> with code owners or patch reviewers for non-trivial changes. >> >> It's not practical to get code owner approval every time. Either because >> there >> is no code owner or because the number of backports is too high (e.g. >> pre-rc1 / pre-rc2). >> This proposed clarification matches how releases are currently managed. >> >> >> ** There is no official release criteria. >> >> We have time-based releases and when the release is 'ready' has been >> up to the discretion of the release manager. Changing the release >> criteria is out of the scope of this proposal, but I do think it would >> be good to have a discussion about this as a community, so I'm going to >> start a separate thread to discuss this. >> >> >> >> *** Proposed Changes *** >> >> >> >> ** Create a time-based bug-fix release schedule. After each major release, >> make >>a new bug-fix release every 2 weeks for 12 weeks (6 releases total). >> >> ** Eliminate release candidates for bug-fix releases. >> >> The current unofficial bug-fix release schedule is: >> >> X.Y.1-rc1 (6 weeks after major release) >> X.Y.1-rc2 (10 weeks after major release) >> X.Y.1-final (12 weeks after major release) >> >> I think this change will improve the overall test coverage of the release >> branch. >> I don't think the branch itself or even the release candidates get the same >> level of testing as the final releases. If we are consistently snapshotting >> the release branch and putting out releases, I think this will make it easier >> and thus more likely that users will test out the release branch code. >> >> Additionally, with more frequent bug-fix release it removes the need to have >> release candidate releases. Every bug-fix release (up until the last one) >> would serve the same purpose as our current release candidates in that they >> are intended to give users an easier way to test the code before the final >> release. Just to confirm: are bug-fix releases X.Y.1 X.Y.2 X.Y.3 ... Seems reasonable. Package maintainers on various distributions may have more words here. It seems that we have a +1 from Gentoo now. >> >> ** Create clear rules for what kind of backports are accepted during each >>release phase. >> >> * Before RC1:Patches should be limited to bug fixes, important optimization >> improvements, or completion of features that were started before the branch >> was created. As with all phases, release managers and code owners can >> reject >> patches that are deemed too invasive. >> >> * Before RC2: Patches should be limited to bug fixes or backend specific >> improvements that are determined to be very safe. >> >> * Before RC3/Final: Major Release* Patches should be limited to critical >> bugs or regressions. >> >> * Bug fix releases: Patches should be limited to bug fixes or very safe >> and critical performance improvements. Patches must maintain both API and >> ABI compatibility with the previous major release. >> >> * Final bug fix release: Patches should be limited to critical bug fixes >> only. >> >> >> >> What does everyone thing about these changes? >> > >Sounds reasonable to me. I think it would certainly benefit users not >to have wait so long for x.1 fixes, and it would mean downstreams have >to backport less. > > >-- >Best regards, >Michał Górny > >___ >cfe-dev mailing list >cfe-...@lists.llvm.org >https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Release-testers] RFC: Release process changes
On 05/21/2020 05:38 PM, Fāng-ruì Sòng wrote: > On 2020-05-21, Michał Górny via cfe-dev wrote: >> On Thu, 2020-05-21 at 11:59 -0700, Tom Stellard via Release-testers >> wrote: >>> Hi, >>> >>> I would like to propose a few changes to the LLVM release process. The >>> current process is documented here: >>> https://llvm.org/docs/HowToReleaseLLVM.html >>> >>> There are two parts to this proposal. The first is a list of >>> clarifications, >>> which are things we are currently doing that aren't documented. The second >>> is a list of changes which would actually modify how releases are currently >>> managed. >>> >>> >>> >>> *** Proposed Clarifications *** >>> >>> >>> >>> ** Release manager is allowed to commit changes to the release branch >>> without >>> code owner approval. However, the release manager is encouraged to >>> consult >>> with code owners or patch reviewers for non-trivial changes. >>> >>> It's not practical to get code owner approval every time. Either because >>> there >>> is no code owner or because the number of backports is too high (e.g. >>> pre-rc1 / pre-rc2). >>> This proposed clarification matches how releases are currently managed. >>> >>> >>> ** There is no official release criteria. >>> >>> We have time-based releases and when the release is 'ready' has been >>> up to the discretion of the release manager. Changing the release >>> criteria is out of the scope of this proposal, but I do think it would >>> be good to have a discussion about this as a community, so I'm going to >>> start a separate thread to discuss this. >>> >>> >>> >>> *** Proposed Changes *** >>> >>> >>> >>> ** Create a time-based bug-fix release schedule. After each major release, >>> make >>>a new bug-fix release every 2 weeks for 12 weeks (6 releases total). >>> >>> ** Eliminate release candidates for bug-fix releases. >>> >>> The current unofficial bug-fix release schedule is: >>> >>> X.Y.1-rc1 (6 weeks after major release) >>> X.Y.1-rc2 (10 weeks after major release) >>> X.Y.1-final (12 weeks after major release) >>> >>> I think this change will improve the overall test coverage of the release >>> branch. >>> I don't think the branch itself or even the release candidates get the same >>> level of testing as the final releases. If we are consistently snapshotting >>> the release branch and putting out releases, I think this will make it >>> easier >>> and thus more likely that users will test out the release branch code. >>> >>> Additionally, with more frequent bug-fix release it removes the need to have >>> release candidate releases. Every bug-fix release (up until the last one) >>> would serve the same purpose as our current release candidates in that they >>> are intended to give users an easier way to test the code before the final >>> release. > > Just to confirm: are bug-fix releases X.Y.1 X.Y.2 X.Y.3 ... > Yes, this is correct. -Tom > Seems reasonable. Package maintainers on various distributions may > have more words here. > It seems that we have a +1 from Gentoo now. > > >>> >>> ** Create clear rules for what kind of backports are accepted during each >>>release phase. >>> >>> * Before RC1:Patches should be limited to bug fixes, important optimization >>> improvements, or completion of features that were started before the >>> branch >>> was created. As with all phases, release managers and code owners can >>> reject >>> patches that are deemed too invasive. >>> >>> * Before RC2: Patches should be limited to bug fixes or backend specific >>> improvements that are determined to be very safe. >>> >>> * Before RC3/Final: Major Release* Patches should be limited to critical >>> bugs or regressions. >>> >>> * Bug fix releases: Patches should be limited to bug fixes or very safe >>> and critical performance improvements. Patches must maintain both API and >>> ABI compatibility with the previous major release. >>> >>> * Final bug fix release: Patches should be limited to critical bug fixes >>> only. >>> >>> >>> >>> What does everyone thing about these changes? >>> >> >> Sounds reasonable to me. I think it would certainly benefit users not >> to have wait so long for x.1 fixes, and it would mean downstreams have >> to backport less. >> >> >> -- >> Best regards, >> Michał Górny >> > > > >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 46029] New: inconsistent behaviors at -O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=46029
Bug ID: 46029
Summary: inconsistent behaviors at -O3 (-O0 is correct)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Created attachment 23515
--> https://bugs.llvm.org/attachment.cgi?id=23515=edit
the binary
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -g -O3 small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 11
Breakpoint 1: where = a.out`foo + 214 at small.c:11:7, address =
0x00401206
(lldb) r
Process 295458 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 295458 exited with status = 0 (0x)
(lldb) q
/
As showed, when setting breakpoint on Line 11, lldb exit directly.
However, when step-i, Line 11 is hit by lldb as follow:
/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:15:3, address =
0x004013b1
(lldb) r
Process 295500 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 295500 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004013b1 a.out`main at small.c:15:3
12 }
13
14 int main() {
-> 15 foo(2, 0);
16 return 0;
17 }
18
(lldb) si -c 19
Process 295500 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x0040135e a.out`foo(r=4210760, n=0) at small.c:11:14
8
9 while(i-->0)
10 if(n==0 || c[r+i]==0)
-> 11 g[r+i] = 0;
12 }
13
14 int main() {
(lldb)
$ cat small.c
int g[10], c[10];
__attribute__ ((noinline))
void foo(int r, int n) {
int i=0;
if(r>g[r])
i=r;
while(i-->0)
if(n==0 || c[r+i]==0)
g[r+i] = 0;
}
int main() {
foo(2, 0);
return 0;
}
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 46030] New: inconsistent behaviors at -O1 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=46030
Bug ID: 46030
Summary: inconsistent behaviors at -O1 (-O0 is correct)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Created attachment 23516
--> https://bugs.llvm.org/attachment.cgi?id=23516=edit
the binary
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -O1 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 10
Breakpoint 1: where = a.out`f + 126 at small.c:10:12, address =
0x0040118e
(lldb) r
Process 310513 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 310513 exited with status = 0 (0x)
(lldb)
/
As showed, when setting breakpoint on Line 10, lldb exit directly.
However, when step-i, Line 10 is hit by lldb as follow:
/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:16:3, address =
0x004011c1
(lldb) r
Process 310470 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 310470 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004011c1 a.out`main at small.c:16:3
13 }
14
15 int main() {
-> 16 f(1, "ab");
17 }
18
(lldb) si -c 25
Process 310470 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x004011ac a.out`f(p=) at small.c:10:12
7 va_start(ap, p);
8 while (1) {
9 v = va_arg(ap, char *);
-> 10 if (!v) break;
11 }
12 va_end(ap);
13 }
(lldb)
$ cat small.c
#include
void f(int p, ...) {
va_list ap;
char *v;
va_start(ap, p);
while (1) {
v = va_arg(ap, char *);
if (!v) break;
}
va_end(ap);
}
int main() {
f(1, "ab");
}
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] 10.0.1-rc1 release has been tagged
On 20 May 2020, at 03:22, Tom Stellard via Release-testers wrote: > > I have just tagged the 10.0.1-rc1 release. Testers can begin testing and > uploading > binaries. > > If you still want to get a fix into the 10.0.1 release, you still have about > a month > to get your fix in. To request a patch be backported to the release/10.x > branch, > file a bug and mark it as a blocker of the release-10.0.1 meta bug. I have uploaded: SHA256 (clang+llvm-10.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 4dbe2041e8aa80ba2b908946052bd4bb20733422707277aa7c297980ed8cd92c SHA256 (clang+llvm-10.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 5fad007fdabe085de126513875a8e601b1f341889eb36423d2980dd3d34b1d80 but none of the regression tests could run, due to a lit/googletest exception: llvm-lit: /home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43: warning: unable to discover google-tests in '/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests': Command '['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests', '--gtest_list_tests']' returned non-zero exit status 1.. Process output: b'' Traceback (most recent call last): File "/home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py", line 39, in getGTestTests env=localConfig.environment) File "/usr/local/lib/python3.7/subprocess.py", line 411, in check_output **kwargs).stdout File "/usr/local/lib/python3.7/subprocess.py", line 512, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests', '--gtest_list_tests']' returned non-zero exit status 1. Running the MLIRSPIRVTests executable shows the actual problem: $ /home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests Shared object "libc++abi.so.1" not found, required by "MLIRSPIRVTests" On FreeBSD we use libcxxrt, not libc++abi. Does anybody have an idea why this appears to have changed between 10.0.0 and 10.0.1? And if so, how I tell the build not to link against libc++abi? -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] 10.0.1-rc1 release has been tagged
On Tue, 2020-05-19 at 18:22 -0700, Tom Stellard via Release-testers wrote: > Hi, > > I have just tagged the 10.0.1-rc1 release. Testers can begin testing and > uploading > binaries. > > If you still want to get a fix into the 10.0.1 release, you still have about > a month > to get your fix in. To request a patch be backported to the release/10.x > branch, > file a bug and mark it as a blocker of the release-10.0.1 meta bug. > Just FYI, the sky seems to have fallen on me here. I'm not really sure why it worked before but a lot of parts of clang fail now due to duplicate registered command-line options. I will file bugs when I'm done figuring out all the fixes but giving you an early heads-up. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] RFC: Release process changes
On Thu, 2020-05-21 at 11:59 -0700, Tom Stellard via Release-testers wrote: > Hi, > > I would like to propose a few changes to the LLVM release process. The > current process is documented here: > https://llvm.org/docs/HowToReleaseLLVM.html > > There are two parts to this proposal. The first is a list of clarifications, > which are things we are currently doing that aren't documented. The second > is a list of changes which would actually modify how releases are currently > managed. > > > > *** Proposed Clarifications *** > > > > ** Release manager is allowed to commit changes to the release branch without > code owner approval. However, the release manager is encouraged to > consult > with code owners or patch reviewers for non-trivial changes. > > It's not practical to get code owner approval every time. Either because > there > is no code owner or because the number of backports is too high (e.g. pre-rc1 > / pre-rc2). > This proposed clarification matches how releases are currently managed. > > > ** There is no official release criteria. > > We have time-based releases and when the release is 'ready' has been > up to the discretion of the release manager. Changing the release > criteria is out of the scope of this proposal, but I do think it would > be good to have a discussion about this as a community, so I'm going to > start a separate thread to discuss this. > > > > *** Proposed Changes *** > > > > ** Create a time-based bug-fix release schedule. After each major release, > make >a new bug-fix release every 2 weeks for 12 weeks (6 releases total). > > ** Eliminate release candidates for bug-fix releases. > > The current unofficial bug-fix release schedule is: > > X.Y.1-rc1 (6 weeks after major release) > X.Y.1-rc2 (10 weeks after major release) > X.Y.1-final (12 weeks after major release) > > I think this change will improve the overall test coverage of the release > branch. > I don't think the branch itself or even the release candidates get the same > level of testing as the final releases. If we are consistently snapshotting > the release branch and putting out releases, I think this will make it easier > and thus more likely that users will test out the release branch code. > > Additionally, with more frequent bug-fix release it removes the need to have > release candidate releases. Every bug-fix release (up until the last one) > would serve the same purpose as our current release candidates in that they > are intended to give users an easier way to test the code before the final > release. > > > ** Create clear rules for what kind of backports are accepted during each >release phase. > > * Before RC1:Patches should be limited to bug fixes, important optimization > improvements, or completion of features that were started before the branch > was created. As with all phases, release managers and code owners can > reject > patches that are deemed too invasive. > > * Before RC2: Patches should be limited to bug fixes or backend specific > improvements that are determined to be very safe. > > * Before RC3/Final: Major Release* Patches should be limited to critical > bugs or regressions. > > * Bug fix releases: Patches should be limited to bug fixes or very safe > and critical performance improvements. Patches must maintain both API and > ABI compatibility with the previous major release. > > * Final bug fix release: Patches should be limited to critical bug fixes only. > > > > What does everyone thing about these changes? > Sounds reasonable to me. I think it would certainly benefit users not to have wait so long for x.1 fixes, and it would mean downstreams have to backport less. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: Release process changes
Hi, I would like to propose a few changes to the LLVM release process. The current process is documented here: https://llvm.org/docs/HowToReleaseLLVM.html There are two parts to this proposal. The first is a list of clarifications, which are things we are currently doing that aren't documented. The second is a list of changes which would actually modify how releases are currently managed. *** Proposed Clarifications *** ** Release manager is allowed to commit changes to the release branch without code owner approval. However, the release manager is encouraged to consult with code owners or patch reviewers for non-trivial changes. It's not practical to get code owner approval every time. Either because there is no code owner or because the number of backports is too high (e.g. pre-rc1 / pre-rc2). This proposed clarification matches how releases are currently managed. ** There is no official release criteria. We have time-based releases and when the release is 'ready' has been up to the discretion of the release manager. Changing the release criteria is out of the scope of this proposal, but I do think it would be good to have a discussion about this as a community, so I'm going to start a separate thread to discuss this. *** Proposed Changes *** ** Create a time-based bug-fix release schedule. After each major release, make a new bug-fix release every 2 weeks for 12 weeks (6 releases total). ** Eliminate release candidates for bug-fix releases. The current unofficial bug-fix release schedule is: X.Y.1-rc1 (6 weeks after major release) X.Y.1-rc2 (10 weeks after major release) X.Y.1-final (12 weeks after major release) I think this change will improve the overall test coverage of the release branch. I don't think the branch itself or even the release candidates get the same level of testing as the final releases. If we are consistently snapshotting the release branch and putting out releases, I think this will make it easier and thus more likely that users will test out the release branch code. Additionally, with more frequent bug-fix release it removes the need to have release candidate releases. Every bug-fix release (up until the last one) would serve the same purpose as our current release candidates in that they are intended to give users an easier way to test the code before the final release. ** Create clear rules for what kind of backports are accepted during each release phase. * Before RC1:Patches should be limited to bug fixes, important optimization improvements, or completion of features that were started before the branch was created. As with all phases, release managers and code owners can reject patches that are deemed too invasive. * Before RC2: Patches should be limited to bug fixes or backend specific improvements that are determined to be very safe. * Before RC3/Final: Major Release* Patches should be limited to critical bugs or regressions. * Bug fix releases: Patches should be limited to bug fixes or very safe and critical performance improvements. Patches must maintain both API and ABI compatibility with the previous major release. * Final bug fix release: Patches should be limited to critical bug fixes only. What does everyone thing about these changes? -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: Release qualification criteria
Hi, I'm splitting this discussion off of my RFC for release process changes. We currently have no official release qualification criteria. In other words, we don't have any blocking tests that need to pass in order to make a new release. We do time-based releases, which is not always compatible with having quality-based criteria for tagging a final release. So, I think another way to look at this issue is to talk about what kinds of CI testing we have for trunk and if there are any additional kinds of testing (e.g. compile-time performance) that we want to prioritize. So, for the purposes of this discussion, I see 2 main questions: 1. Should we define some set of blocking tests that need to pass before a release can happen? 2. What gaps do we currently have in our CI testing? ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
