[mlir][scf] Interpret trip counts as unsigned integers (#178060)
Trip counts represent iteration counts and are always non-negative. This
PR fixes all call sites to correctly use `getZExtValue()` instead of
`getSExtValue()` when extracting trip count values from `APInt`. Also
documents to clarify results are unsigned.
interfaces: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
Set virtual_oss_enable="NO" in /etc/defaults/rc.conf
This prevents 'service -e' from emitting (/var/log/messages):
/usr/sbin/service: WARNING: $virtual_oss_enable is not set properly - see rc.conf(5)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1987
Reviewed by: christos
Signed-off-by: eborisch at gmail.com
MFC after: 1 week
[clang][unittests] Fix linker error for DirectoryWatcherTest with CLANG_LINK_CLANG_DYLIB (#178455)
Move clangDirectoryWatcher from LINK_LIBS to CLANG_LIBS so it gets
replaced by clang-cpp when building with CLANG_LINK_CLANG_DYLIB=ON.
When using both CLANG_LINK_CLANG_DYLIB=ON and LLVM_ENABLE_LTO=Thin, the
test would fail with:
ld.lld: error: undefined symbol:
clang::DirectoryWatcher::create(llvm::StringRef, std::function<void
(llvm::ArrayRef
This happens because clangDirectoryWatcher was being linked as a
separate library alongside clang-cpp (which already contains
clangDirectoryWatcher), causing duplicate symbol issues with LTO.
The fix correctly categorizes:
- clangDirectoryWatcher → CLANG_LIBS (Clang library, bundled in
clang-cpp)
- LLVMTestingSupport → LINK_LIBS (LLVM library, always linked directly)
#178302
[mlir][NVVM] Add support for tcgen05.ld.red Op (#177330)
The commit adds the following:
- Adds tcgen05.ld.red Op with tests under tcgen05-ld-red.mlir and
tcgen05-ld-red-invalid.mlir
- Renamed ReduxKind to ReductionKind and renamed it across NVVM and GPU
Dialects
- Replaced Tcgen05LdRedOperationAtr with ReductionKindAttr
- Updated tcgen05.ld.red and nvvm.redux.sync tests
[lldb] Make `print` delegate to synthetic frames.
This patch is more of a proposal in that it's a pretty dramatic change to the way that `print` works. It completely delegates getting values to the frame if the frame is synthetic, and does not redirect at all if the frame fails.
For this patch, the main goal was to allow the synthetic frame to bubble up its own errors in expression evaluation, rather than having errors come back with an extra "could not find identifier <blah>" or worse, simply get swallowed. If there's a better way to handle this, I'm more than happy to change this as long as the core goals of 'delegate variable/value extraction to the synthetic frame', and 'allow the synthetic frame to give back errors that are displayed to the user' can be met.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178602, branch: users/bzcheeseman/stack/7
Change the high-level FUSE implementation to use the low-level API.
Currently, both APIs communicate with the kernel independently.
Even though this is a libfuse change, I've included a minor kernel
patch to remove a now unecessary check for a ENOBUFS errno. This
is not part of the FUSE protocol and is no longer needed.
I've also deleted a regression test, which checks that libfuse
functions can handle NULL as an argument. It's better that these
function segfault rather than attempt to gracefully handle bad
arguments.
There is no change to the libfuse API so shlib_version does not need a
bump.
OK claudio@
[lldb] Add support for ScriptedFrame to provide values/variables.
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178575, branch: users/bzcheeseman/stack/6
[lldb] Add conversions for SBValueList and SBValue to the python bridge.
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178574, branch: users/bzcheeseman/stack/5
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC.
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178573, branch: users/bzcheeseman/stack/4
[clang][bytecode] Only check static lambda captures if we have to (#178452)
Call `getCaptureFields()` only if the function is static, because we
only care about the captures in that case.
