[lldb-dev] [11.0.0 Release] The release branch is here; trunk is now 12.0.0
Hello everyone, The release branch for LLVM 11 was created from the trunk at 2e10b7a39b930ef8d9c4362509d8835b221fbc0a, and the trunk version was bumped to 12.0.0. Release blockers are tracked by https://llvm.org/PR46725 Please mark any bugs, old or new, that need to be fixed before the release as blocking that bug. Please keep me in the loop via email on any bugs, commits, or other issues that might be relevant for the release. In particular, if you're currently investigating issues with trunk and working on fixes, please help me make sure that those fixes end up on the branch also. To get a change committed to the branch, please commit it to trunk as per usual, and then request it to be merged -- ideally by filing a blocker of https://llvm.org/PR46725, or by cc'ing me on the commit email. (Please don't report issues or request merges over IRC/Discord/Discourse; there's a large risk that I'll miss it. Please use email.) The first release candidate will be tagged soon (hopefully in a day or two if the branch looks stable), and testing of that can begin. The full release schedule can be found under "Upcoming Releases" to the right at https://llvm.org Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Release-testers] 10.0.1-rc4 tagged
On 7/14/20 8:35 PM, Brian Cain wrote: -Original Message- From: llvm-dev On Behalf Of Tom Stellard via llvm-dev ... On 7/9/20 7:42 PM, Brian Cain wrote: Uploaded: dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2 clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz 6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7 clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz 2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xz ccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131 clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz 761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1 clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xz I saw phase2/3 mismatches that seem concerning. Are these the only platforms that encountered them? I can open a bug, let me know if there's particular data beyond the logs I should gather. Can you attach 2 of the binary files the are different? Attached a few from each impacted platform. Additional notes below. # for ubuntu16, 10.0.1-rc4: $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l 14 $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log file omptarget-nvptx_intermediate_link.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_target_impl.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_reduction.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_omptarget.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_support.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_libcall.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_critical.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_data_sharing.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_task.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_cancel.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_sync.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_loop.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_parallel.cu.o differs between phase 2 and phase 3 ~~ The difference in ubuntu 10.0.1-rc4 are in the '__nv_module_id' section of binaries, which contains a GUID that is unique to the binary, so this is expected. # for sles12, 10.0.1-rc3: $ grep 'differs between' rc3/logs/testing.10.0.1-rc3.log |wc -l 4860 $ tail rc3/logs/testing.10.0.1-rc3.log file interface.cpp.o differs between phase 2 and phase 3 file rtl.cpp.o differs between phase 2 and phase 3 file omptarget.cpp.o differs between phase 2 and phase 3 file ompt-tsan.cpp.o differs between phase 2 and phase 3 file ompt-tsan.cpp.o differs between phase 2 and phase 3 file Bye.cpp.o differs between phase 2 and phase 3 file TestPlugin.cpp.o differs between phase 2 and phase 3 file PipSqueak.cpp.o differs between phase 2 and phase 3 file PipSqueak.cpp.o differs between phase 2 and phase 3 file ExportedFuncs.cpp.o differs between phase 2 and phase 3 Do you get these same failures on sles with rc4? -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [llvm-dev] 10.0.1-rc4 tagged
On 7/15/20 1:07 PM, Tom Stellard via Release-testers wrote: On 7/14/20 8:35 PM, Brian Cain wrote: -Original Message- From: llvm-dev On Behalf Of Tom Stellard via llvm-dev ... On 7/9/20 7:42 PM, Brian Cain wrote: Uploaded: dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2 clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz 6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7 clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz 2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xz ccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131 clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz 761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1 clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xz I saw phase2/3 mismatches that seem concerning. Are these the only platforms that encountered them? I can open a bug, let me know if there's particular data beyond the logs I should gather. Can you attach 2 of the binary files the are different? Attached a few from each impacted platform. Additional notes below. # for ubuntu16, 10.0.1-rc4: $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l 14 $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log file omptarget-nvptx_intermediate_link.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_target_impl.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_reduction.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_omptarget.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_support.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_libcall.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_critical.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_data_sharing.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_task.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_cancel.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_sync.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_loop.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and phase 3 file omptarget-nvptx_generated_parallel.cu.o differs between phase 2 and phase 3 ~~ The difference in ubuntu 10.0.1-rc4 are in the '__nv_module_id' section of binaries, which contains a GUID that is unique to the binary, so this is expected. # for sles12, 10.0.1-rc3: $ grep 'differs between' rc3/logs/testing.10.0.1-rc3.log |wc -l 4860 $ tail rc3/logs/testing.10.0.1-rc3.log file interface.cpp.o differs between phase 2 and phase 3 file rtl.cpp.o differs between phase 2 and phase 3 file omptarget.cpp.o differs between phase 2 and phase 3 file ompt-tsan.cpp.o differs between phase 2 and phase 3 file ompt-tsan.cpp.o differs between phase 2 and phase 3 file Bye.cpp.o differs between phase 2 and phase 3 file TestPlugin.cpp.o differs between phase 2 and phase 3 file PipSqueak.cpp.o differs between phase 2 and phase 3 file PipSqueak.cpp.o differs between phase 2 and phase 3 file ExportedFuncs.cpp.o differs between phase 2 and phase 3 Do you get these same failures on sles with rc4? It looks like the difference in the objects on sles is because the compiler ID string in phase 2 and phase 3 have a different git commit hash. The git hash in the phase 3 binaries is acd921f02c39fa5cf7aa055b6062bfe9025e3781, which I don't see in the llvm git tree. -Tom -Tom ___ Release-testers mailing list release-test...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [11.0.0 Release] The release branch is here; trunk is now 12.0.0
Thanks for tagging, Hans. Can I go ahead with the CMake version bump advertised in http://lists.llvm.org/pipermail/llvm-dev/2020-June/142893.html? This may cause some instability on a few builders that have not upgraded to a recent CMake yet, but I'll iterate as explained in the linked thread. Let me know if it's OK to go ahead now or if you'd prefer that I wait for a few days. Cheers, Louis > On Jul 15, 2020, at 08:09, Hans Wennborg via llvm-dev > wrote: > > Hello everyone, > > The release branch for LLVM 11 was created from the trunk at > 2e10b7a39b930ef8d9c4362509d8835b221fbc0a, and the trunk version was > bumped to 12.0.0. > > Release blockers are tracked by https://llvm.org/PR46725 Please mark > any bugs, old or new, that need to be fixed before the release as > blocking that bug. > > Please keep me in the loop via email on any bugs, commits, or other > issues that might be relevant for the release. In particular, if > you're currently investigating issues with trunk and working on fixes, > please help me make sure that those fixes end up on the branch also. > > To get a change committed to the branch, please commit it to trunk as > per usual, and then request it to be merged -- ideally by filing a > blocker of https://llvm.org/PR46725, or by cc'ing me on the commit > email. > > (Please don't report issues or request merges over > IRC/Discord/Discourse; there's a large risk that I'll miss it. Please > use email.) > > The first release candidate will be tagged soon (hopefully in a day or > two if the branch looks stable), and testing of that can begin. The > full release schedule can be found under "Upcoming Releases" to the > right at https://llvm.org > > Thanks, > Hans > ___ > 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] LLDB SBAPI questions
> On Jul 14, 2020, at 3:13 PM, Vadim Chugunov via lldb-dev
> wrote:
>
> Hi,
> I've a couple of questions:
>
> 1. Is there a way to get numeric values of C++ template parameters?SBType
> has a method for discovering argument kind and type, but I couldn't find
> anything for values.
You are correct, this isn't implemented. Any patches for adding this would be
great! A nice API might be:
class SBType {
SBValue GetTemplateArgumentValue(uint32_t idx);
};
We would need to use SBValue because the argument value can have any type
(bool, int, etc). It might also not have a value for non-numeric template
types, in which case a SBValue would be returned and if you ask it for its
error, it would return a SBError value with a suitable error message declaring
so.
>
> 2. Can I enumerate static variables of a class via SBType? (and read their
> values)
No, but this would be another nice addition to the interface. The interesting
issue here is a type declaration is not tied to a location for the variable.
Any SBModule could contain a type declaration that includes static variables,
but only one module might actually contain the actual values. So the API we add
will need to take a SBTarget. Something like:
class SBType {
SBValue GetClassVariable(SBTarget target, uint32_t idx);
};
If the target isn't valid, we can probably still return a SBValue that has the
name, type and kind that matches the global or static variable. You can ask the
SBValue fo:
ValueType SBValue::GetValueType();
Which would return eValueTypeVariableGlobal or eValueTypeVariableStatic. I
would guess eValueTypeVariableGlobal is the more correct value here as static
is a C++ terminology for a class global variable.
If the target is valid, then the code would need to try and locate the module
that actually contains this variable and find its address using the symbol
table or debug info and return the SBValue with everything set correctly.
So yes, neither of these are in the API, but would be great additions! We are
more than willing to help review any patches that make this happen.
Greg
>
> thanks!
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
