[flang][docs] Fix typo in array description #135822
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
…vm#134339) # Summary This PR updates `SBProcess::GetNumThreads()` and `SBProcess::GetThreadAtIndex()` to listen to the stop locker. `SBProcess::GetNumThreads()` will return 0 if the process is running. ## Problem Description Recently upon debugging a program with thousands of threads in VS Code, lldb-dap would hang at a `threads` request sent right after receiving the `configurationDone` response. Soon after it will end the debug session with the following error ``` Process <pid> exited with status = -1 (0xffffffff) lost connection ``` This is because LLDB is still in the middle of resuming all the threads. And requesting threads will end up interrupt the process on Linux. From the gdb-remote log it ended up getting `lldb::StateType::eStateInvalid` and just exit with status -1. I don't think it's reasonable to allow getting threads from a running process. There are a few approaches to fix this: 1) Send the stopped event to IDE after `configurationDone`. This aligns with the CLI behavior. 2) However, the above approach will break the existing user facing behavior. The alternative will be reject the `threads` request if the process is not stopped. 3) Improve the run lock. This is a synchronize issue where process was in the middle of resuming while lldb-dap attempts to interrupt it. **This PR implements the option 3** ## HOWEVER This fixed the "lost connection" issue below but new issue has surfaced. From testing, and also from checking the [VSCode source code](https://github.com/microsoft/vscode/blob/174af221c9ea2ccdb64abe4aab8e1a805e77beae/src/vs/workbench/contrib/debug/browser/debugSession.ts#L791), it expects having threadID to perform `pause`. So after attaching, without any threads reported to the client, the user will not be able to pause the attached process. `setBreakpoint` will still work and once we make a stop at the bp (or any stop that will report threads, client can perform pause again. ## NEXT 1) Made an attempt to return initial thread list so that VSCode can pause (second commit in the PR) 2) Investigate why threads will trigger unwinding the second frame of a thread, which leads to sending the interrupt 3) Decided if we want to support `stopOnEntry` for attaching, given i. This is not an official specification ii. If enable stopOnEntry, we need to fix attaching on Linux, to send only one stopped event. Currently, all threads upon attaching will have stop reason `SIGSTOP` and lldb-dap will send `stopped` event for each one of them. Every `stopped` will trigger the client request for threads. iii. Alternatively, we can support auto continue correspond to `(lldb) process attach --continue`. This require the ii above. ### Additionally lldb-dap will not send a `continued` event after `configurationDone` because it checks `dap.focus_tid == LLDB_INVALID_THREAD_ID` (so that we don't send it for `launch` request). Notice `dap.focus_tid` will only get assigned when handling stop or stepping. According to DAP > Please note: a debug adapter is not expected to send this event in response to a request that implies that execution continues, e.g. launch or continue. It is only necessary to send a continued event if there was no previous request that implied this. So I guess we are not violating DAP if we don't send `continued` event. But I'd like to get some sense about this. ## Test Plan Used following program for testing: https://gist.github.com/kusmour/1729d2e07b7b1063897db77de194e47d **NOTE: Utilize stdin to get pid and attach AFTER hitting enter. Attach should happen when all the threads start running.** DAP messages before the change <img width="1165" alt="image" src="https://github.com/user-attachments/assets/a9ad85fb-81ce-419c-95e5-612639905c66" /> DAP message after the change - report zero threads after attaching <img width="1165" alt="image" src="https://github.com/user-attachments/assets/a1179e18-6844-437a-938c-0383702294cd" /> --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This macro is a no-op after 90c001a: libc_function macro now produce a "regular" cc_library target, without modifying its name, and this target is intended to only be used in tests. Thus, libc_internal_target macro is no longer needed, and we can safely treat libc_function rules and libc_support_library rules identically for test purposes. `libc_function_deps` attribute of a `libc_test` macro can also be cleaned up, but I plan to do this in a subsequent change.
…etc) ## Purpose Add documentation for the existing family of `LLVM_ABI` annotation macros defined in llvm/Support/Compiler.h. These annotations are used to describe LLVM's public interface. ## Background This documentation is in support of the annotation effort described [here](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307/). ## Validation Manually inspected rendered ReST document on GitHub. Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
…r base (llvm#135493) This change adds an ArraySubscriptExpr from the function parameter with base type as Pointer Issue llvm#130197
It can be represented using a regular MOVK instruction which also has the advantage of sometimes being selectable without a preceding MOV. Reviewers: ahmedbougacha, asl, atrosinenko Reviewed By: atrosinenko Pull Request: llvm#134765
The purpose of this flag is to allow the compiler to assume that each object file passed to the linker has been compiled using a unique source file name. This is useful for reducing link times when doing ThinLTO in combination with whole-program devirtualization or CFI, as it allows modules without exported symbols to be built with ThinLTO. Reviewers: vitalybuka, teresajohnson Reviewed By: teresajohnson Pull Request: llvm#135728
…o get more stack space (llvm#133173) Clang spawns a new thread to avoid running out of stack space. This can make debugging and performance analysis more difficult as how the threads are connected is difficult to recover. This patch introduces `runOnNewStack` and applies it in Clang. On platforms that have good support for it this allocates a new stack and moves to it using assembly. Doing split stacks like this actually runs on most platforms, but many debuggers and unwinders reject the large or backwards stack offsets that occur. Apple platforms and tools are known to support this, so this only enables it there for now.
The new version of the OpenACC specification will allow the if clause on the atomic directives. Allow it in `ACC.td` and update the parse node and parser in flang to support it. OpenACC dialect will need to be updated to support it as well.
…m#133183) Makes it less confusing as this function only matches the number of elements
…33574) After builtin macro expansion in `Preprocessor::ExpandBuiltinMacro` the result token may have the `Token::NeedsCleaning` flag set which causes an assertion failure later on when the lexer retrieves the spelling of the token in `getSpellingSlow`. This commit adds an `Tok.clearFlag(Token::NeedsCleaning)` call to the end of `ExpandBuiltinMacro`. Closes llvm#128384
…llvm#135698) The recipe for initializing private box types was incorrect because hlfir::createTempFromMold() is not a suitable utility function when the box element type is a trivial type.
This adds missing error_if checking for Transpose Op also moved all transpose op's verifier tests from invalid.mlir to verifier.mlir Signed-off-by: Tai Ly <tai.ly@arm.com>
Add table size check for Table Op and add lit tests to error_if_check.mlir also corrected some existing tests that violated the table size checks Signed-off-by: Tai Ly <tai.ly@arm.com>
thread.h used report_fatal_error without including ErrorHandling.h
If we are replacing a sequence of stack nodes with a single node representing inlined IR, and the stack id sequence contains recursion, we may have already removed some edges. Handle this case correctly by skipping the now removed edge.
The qualifier allows programmer to directly control how pointers are signed when they are stored in a particular variable. The qualifier takes three arguments: the signing key, a flag specifying whether address discrimination should be used, and a non-negative integer that is used for additional discrimination. ``` typedef void (*my_callback)(const void*); my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback; ``` Co-Authored-By: John McCall rjmccall@apple.com
Reviewers: efriedma-quic, teresajohnson Reviewed By: teresajohnson, efriedma-quic Pull Request: llvm#135832
If the potential split node is a perfect/shuffled match of another split node, need to skip creation of the another split node with the same scalars, it should be a buildvector. Fixes llvm#135800
Some functions have their sizes as zero in input binary's symbol table, like those compiled by assembler. When figuring out function sizes, we may create label symbol if it doesn't point to any constant island. However, before function size is known, marker symbol can not be correctly associated to a function and therefore all such checks would fail and we could end up adding a code label pointing to constant island as secondary entry point and later mistakenly marking the function as not simple. Querying the global marker symbol array has big throughput overhead. Instead we can run an extra check when post processing entry points to identify such label symbols that actually point to constant islands.
…35684) Previously the error only contained the failed to parse JSON message, which has no additional context. This improves the error messages and improves the consistency of handling properties in protocol structures. Updating the fields to use 'ObjectMapper.map' instead of 'ObjectMapper.mapOptional' caught that adapterID was misspelled as well. For example, previously: ``` $ echo 'Content-Length: 81\r\n\r\n{"type":"request","command":"initialize","seq":1,"arguments":{"adapterID":12345}} | lldb-dap ``` Worked without an error but now it reports: ``` invalid arguments for request 'initialize': expected string at arguments.adapterID { "adapterID": /* error: expected string */ 12345 } ```
FOr the split node number of operands should be requested via getNumOperands() function, even if the main op is CallInst.
…llvm#135014) Motivation: amdgpu buffer load instruction will return all zeros when loading sub-word values. For example, assuming the buffer size is exactly one word and we attempt to invoke `llvm.amdgcn.raw.ptr.buffer.load.v2i32` starting from byte 2 of the word, we will not receive the actual value of the buffer but all zeros for the first word. This is because the boundary has been crossed for the first word. This PR come up with a fix to this problem, such that, it creates a bounds check against the buffer load instruction. It will compare the offset + vector size to see if the upper bound of the address will exceed the buffer size. If it does, masked transfer read will be optimized to `vector.load` + `arith.select`, else, it will continue to fall back to default lowering of the masked vector load.
This is a fairly light-weight traversal and is needed in instrumentation. No need to run the whole `FunctionAttrs` pass at this stage. To avoid layering issues, this patch factors `canRun` and related under Analysis/CFG.
…r. (llvm#135838) Use getTypeAction instead of trying to guess how a type will be legalized. On AArch64, v1f16 is scalarized but v1f16 is widened. Fixes llvm#135776
Reviewers: brad0, s-barannikov, rorth Reviewed By: s-barannikov Pull Request: llvm#135713
…VIS3 Reviewers: s-barannikov, rorth, brad0 Reviewed By: s-barannikov Pull Request: llvm#135714
…te branch (llvm#135771) If there is another branch instruction also with immediate operand, but it is used to specify which bit to be tested is set or clear. We only check whether operand2 is immediate or not here. There are no way to distinguish between them. So add new CondCode COND_CV_BEQIMM/COND_CV_BNEIMM that we can know what kinds of immediate branch instruction are matched in Select_* Pseudo.
…we have VIS3" (llvm#135897) This change breaks multiply tests on SPARC. https://lab.llvm.org/buildbot/#/builders/108/builds/11691/steps/6/logs/FAIL__LLVM__multiply-extension_ll Reverts llvm#135714
The 8 and 16 bit LEA instruction support was added by PR llvm#122102, and we have to update creating index register negations accordingly. The issue is exposed with APX NDD instructions.
…geting mips3 (llvm#130558) issue reason: Because mips3 has the feature 'FeatureGP64Bit', when target mips3 process function `writeVarArgRegs`, the result of `getGPRSizeInBytes` is 8 and the result of `GetVarArgRegs` is `Mips::A0, Mips::A1, Mips::A2, Mips::A3`. This would generate `gpr64 = COPY $a1` which should be `gpr64 = COPY $a1_64`. Also when process `CC_Mips_FixedArg`, mips would CCDelegateTo `CC_MipsO32_FP`. In fact, it should CCDelegateTo `CC_MipsN`. Fix llvm#98716.
…rArc (llvm#135532) WebKit uses #define to rename RetainPtr to RetainPtrArc so add the support for it.
…lvm#135835) libc_function_deps and deps are now identical, as we no longer need or have special treatment for libc_function targets. Merge these attributes passed to the libc_test macro, and fix all relevant libc_test macro invocations. This change is a no-op. This concludes cleanup started in 9b13d34.
Add two new format functions for printing ranges: `interleaved` and
`interleaved_array`.
This is meant to improve the ergonomics of printing ranges. Before this
patch, we have to either use `llvm::interleave` or write a for loop by
hand. For example:
Before:
```c++
ArrayRef<Type> types = ...;
ArrayRef<Values> values = ...;
LLVM_DEBUG({
llvm::dbgs() << "Types: ";
llvm::interleave_comma(llvm::dbgs(), types);
llvm::dbgs() << "\n";
llvm::dbgs() << "Values: [";
llvm::interleave_comma(llvm::dbgs(), values);
llvm::dbgs() << "]\n";
}):
```
After:
```c++
ArrayRef<Type> types = ...;
ArrayRef<Values> values = ...;
LLVM_DEBUG(llvm::dbgs() << "Types: " << interleaved(types) << "\n");
LLVM_DEBUG(llvm::dbgs() << "Values: " << interleaved_array(values) << "\n");
```
The separator and the prefix/suffix strings are customizable.
…lvm#132904) Adds support for lowering `do concurrent` nests from PFT to the new `fir.do_concurrent` MLIR op as well as its special terminator `fir.do_concurrent.loop` which models the actual loop nest. To that end, this PR emits the allocations for the iteration variables within the block of the `fir.do_concurrent` op and creates a region for the `fir.do_concurrent.loop` op that accepts arguments equal in number to the number of the input `do concurrent` iteration ranges. For example, given the following input: ```fortran do concurrent(i=1:10, j=11:20) end do ``` the changes in this PR emit the following MLIR: ```mlir fir.do_concurrent { %22 = fir.alloca i32 {bindc_name = "i"} %23:2 = hlfir.declare %22 {uniq_name = "_QFsub1Ei"} : (!fir.ref<i32>) -> (!fir.ref<i32>, !fir.ref<i32>) %24 = fir.alloca i32 {bindc_name = "j"} %25:2 = hlfir.declare %24 {uniq_name = "_QFsub1Ej"} : (!fir.ref<i32>) -> (!fir.ref<i32>, !fir.ref<i32>) fir.do_concurrent.loop (%arg1, %arg2) = (%18, %20) to (%19, %21) step (%c1, %c1_0) { %26 = fir.convert %arg1 : (index) -> i32 fir.store %26 to %23#0 : !fir.ref<i32> %27 = fir.convert %arg2 : (index) -> i32 fir.store %27 to %25#0 : !fir.ref<i32> } } ```
…into fix-typo-0416
Mxfg-incense
requested review from
rupprecht,
keith,
aaronmondal,
aaupov,
maksfb,
rafaelauler,
ayermolo,
dcci,
yota9,
hanhanW,
nicolasvasilache,
JDevlieghere,
lanza,
bcardosolopes and
a team
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.