Hans Wennborg via llvm-dev
2020-Dec-01 18:21 UTC
[llvm-dev] [Release-testers] LLVM 11.0.1-rc1 has been tagged
Hmm, but unless you're doing this on an arm64 machine, you won't be able to run the tests in Phase2 and 3? On Tue, Dec 1, 2020 at 4:36 PM Tobias Hieta <tobias at plexapp.com> wrote:> > Yeah you can pass -DCMAKE_OSX_ARCHITECTURES=arm64;x86_64 and it will > make fat binaries. > > But it seems like we should probably do two packages. That probably > needs to be implemented in the test-release in the following way: > > Build Phase1 for the host currently running on. Then build Phase2 and > 3 for the target (arm64) and compare those. > > Anything I am not thinking about here or missing? > > -- Tobias > > On Tue, Dec 1, 2020 at 4:32 PM Hans Wennborg <hans at chromium.org> wrote: > > > > I think the separate packages make the most sense. > > > > Also, how would one practically go about doing the fat binary > > approach? Is there some cmake magic that would make it > > straight-forward? > > > > On Tue, Dec 1, 2020 at 4:13 PM Tobias Hieta via Release-testers > > <release-testers at lists.llvm.org> wrote: > > > > > > I just realized that we should probably make an arm64 build as well > > > for those new fancy mac's. > > > > > > What do people think is the best solution here, a fat universal build > > > that will be double the size (currently llvm+clang is already ~400MB > > > packed so it will be very big), or two separate builds? > > > > > > The pro of having two separate builds is that we can set the correct > > > default triple instead of a single one, the downside is that I need to > > > build it twice for every version. > > > > > > -- Tobias > > > > > > On Tue, Dec 1, 2020 at 4:03 PM Tobias Hieta <tobias at plexapp.com> wrote: > > > > > > > > Tom, > > > > > > > > MacOS build: clang+llvm-11.0.1-rc1-x86_64-apple-darwin.tar.xz > > > > with SHA256: c9ee87d7e42df8494a9f42993ed499479b3ce118c940a6e8907d075ceb913223 > > > > is uploaded. > > > > > > > > The same tests as before failed: > > > > > > > > FAIL: libunwind :: libunwind_01.pass.cpp (69255 of 69302) > > > > FAIL: libunwind :: signal_frame.pass.cpp (69258 of 69302) > > > > > > > > I had to use the following patch to use Python 3: > > > > > > > > diff --git a/openmp/runtime/test/lit.cfg b/openmp/runtime/test/lit.cfg > > > > index 357b18a205d..96c0c3a1da7 100644 > > > > --- a/openmp/runtime/test/lit.cfg > > > > +++ b/openmp/runtime/test/lit.cfg > > > > @@ -76,7 +76,7 @@ if config.operating_system == 'Darwin': > > > > cmd = subprocess.Popen(['xcrun', '--show-sdk-path'], > > > > stdout=subprocess.PIPE, stderr=subprocess.PIPE) > > > > out, err = cmd.communicate() > > > > - out = out.strip() > > > > + out = out.strip().decode() > > > > res = cmd.wait() > > > > if res == 0 and out: > > > > config.test_flags += " -isysroot " + out > > > > > > > > otherwise tests failed to run. > > > > > > > > On Thu, Nov 26, 2020 at 8:21 AM Tom Stellard via Release-testers > > > > <release-testers at lists.llvm.org> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I've tagged LLVM 11.0.1-rc1. Testers may begin testing and uploading > > > > > binaries. If you still have bugs you want fixed in LLVM 11.0.1, you > > > > > have until Dec. 8 to request backports. You can make these requests by > > > > > filing a bug at bugs.llvm.org and putting release-11.0.1 in the 'blocks' > > > > > field. > > > > > > > > > > -Tom > > > > > > > > > > _______________________________________________ > > > > > Release-testers mailing list > > > > > Release-testers at lists.llvm.org > > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > _______________________________________________ > > > Release-testers mailing list > > > Release-testers at lists.llvm.org > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
Tobias Hieta via llvm-dev
2020-Dec-01 18:49 UTC
[llvm-dev] [Release-testers] LLVM 11.0.1-rc1 has been tagged
Thats a very good point. Maybe someone with an M1 machine can take on the task of testing releases on those? I would happily do that but I don't have such a machine and can't afford one right now unfortunately. -- Tobias On Tue, Dec 1, 2020, 19:21 Hans Wennborg <hans at chromium.org> wrote:> Hmm, but unless you're doing this on an arm64 machine, you won't be > able to run the tests in Phase2 and 3? > > On Tue, Dec 1, 2020 at 4:36 PM Tobias Hieta <tobias at plexapp.com> wrote: > > > > Yeah you can pass -DCMAKE_OSX_ARCHITECTURES=arm64;x86_64 and it will > > make fat binaries. > > > > But it seems like we should probably do two packages. That probably > > needs to be implemented in the test-release in the following way: > > > > Build Phase1 for the host currently running on. Then build Phase2 and > > 3 for the target (arm64) and compare those. > > > > Anything I am not thinking about here or missing? > > > > -- Tobias > > > > On Tue, Dec 1, 2020 at 4:32 PM Hans Wennborg <hans at chromium.org> wrote: > > > > > > I think the separate packages make the most sense. > > > > > > Also, how would one practically go about doing the fat binary > > > approach? Is there some cmake magic that would make it > > > straight-forward? > > > > > > On Tue, Dec 1, 2020 at 4:13 PM Tobias Hieta via Release-testers > > > <release-testers at lists.llvm.org> wrote: > > > > > > > > I just realized that we should probably make an arm64 build as well > > > > for those new fancy mac's. > > > > > > > > What do people think is the best solution here, a fat universal build > > > > that will be double the size (currently llvm+clang is already ~400MB > > > > packed so it will be very big), or two separate builds? > > > > > > > > The pro of having two separate builds is that we can set the correct > > > > default triple instead of a single one, the downside is that I need > to > > > > build it twice for every version. > > > > > > > > -- Tobias > > > > > > > > On Tue, Dec 1, 2020 at 4:03 PM Tobias Hieta <tobias at plexapp.com> > wrote: > > > > > > > > > > Tom, > > > > > > > > > > MacOS build: clang+llvm-11.0.1-rc1-x86_64-apple-darwin.tar.xz > > > > > with SHA256: > c9ee87d7e42df8494a9f42993ed499479b3ce118c940a6e8907d075ceb913223 > > > > > is uploaded. > > > > > > > > > > The same tests as before failed: > > > > > > > > > > FAIL: libunwind :: libunwind_01.pass.cpp (69255 of 69302) > > > > > FAIL: libunwind :: signal_frame.pass.cpp (69258 of 69302) > > > > > > > > > > I had to use the following patch to use Python 3: > > > > > > > > > > diff --git a/openmp/runtime/test/lit.cfg > b/openmp/runtime/test/lit.cfg > > > > > index 357b18a205d..96c0c3a1da7 100644 > > > > > --- a/openmp/runtime/test/lit.cfg > > > > > +++ b/openmp/runtime/test/lit.cfg > > > > > @@ -76,7 +76,7 @@ if config.operating_system == 'Darwin': > > > > > cmd = subprocess.Popen(['xcrun', '--show-sdk-path'], > > > > > stdout=subprocess.PIPE, stderr=subprocess.PIPE) > > > > > out, err = cmd.communicate() > > > > > - out = out.strip() > > > > > + out = out.strip().decode() > > > > > res = cmd.wait() > > > > > if res == 0 and out: > > > > > config.test_flags += " -isysroot " + out > > > > > > > > > > otherwise tests failed to run. > > > > > > > > > > On Thu, Nov 26, 2020 at 8:21 AM Tom Stellard via Release-testers > > > > > <release-testers at lists.llvm.org> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I've tagged LLVM 11.0.1-rc1. Testers may begin testing and > uploading > > > > > > binaries. If you still have bugs you want fixed in LLVM 11.0.1, > you > > > > > > have until Dec. 8 to request backports. You can make these > requests by > > > > > > filing a bug at bugs.llvm.org and putting release-11.0.1 in the > 'blocks' > > > > > > field. > > > > > > > > > > > > -Tom > > > > > > > > > > > > _______________________________________________ > > > > > > Release-testers mailing list > > > > > > Release-testers at lists.llvm.org > > > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > _______________________________________________ > > > > Release-testers mailing list > > > > Release-testers at lists.llvm.org > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/b911e2e6/attachment.html>