Skip to content

[DO NOT MERGE] Creating a test PR to test github action changes #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: retry-flakey
Choose a base branch
from
Open

[DO NOT MERGE] Creating a test PR to test github action changes #1

wants to merge 1 commit into from

Conversation

dmpots
Copy link
Owner

@dmpots dmpots commented Jun 27, 2025

No description provided.

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

Activity Summary:

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

1 similar comment
@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

Activity Summary:

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

Activity Summary:

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

@dmpots
Copy link
Owner Author

dmpots commented Jun 27, 2025

Activity Summary:

@dmpots
Copy link
Owner Author

dmpots commented Jun 30, 2025

@dmpots thank you for applying for commit access. Please review the project's code review policy.

@dmpots
Copy link
Owner Author

dmpots commented Jun 30, 2025

Activity Summary:

dmpots pushed a commit that referenced this pull request Jul 15, 2025
@jurahul
[LLVM] Fix an ASAN error in lookupLLVMIntrinsicByName (llvm#147444)
183f1ac 
Fix unnecessary conversion of C-String to StringRef in the `Cmp` lambda
inside `lookupLLVMIntrinsicByName`. This both fixes an ASAN error in the
code that happens when the `Name` StringRef passed in is not a Null
terminated StringRef, and additionally can potentially speed up the code
as well by eliminating the unnecessary computation of string length
every time a C String is converted to StringRef in this code (It seems
practically this computation is eliminated in optimized builds, but this
will avoid it in O0 builds as well).

Added a unit test that demonstrates this issue by building LLVM with
these options:

```
CMAKE_BUILD_TYPE=Debug
LLVM_USE_SANITIZER=Address
LLVM_OPTIMIZE_SANITIZED_BUILDS=OFF
```

The error reported is as follows:

```
==462665==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5030000391a2 at pc 0x56525cc30bbf bp 0x7fff9e4ccc60 sp 0x7fff9e4cc428
READ of size 19 at 0x5030000391a2 thread T0
    #0 0x56525cc30bbe in strlen (upstream-llvm-second/llvm-project/build/unittests/IR/IRTests+0x713bbe) (BuildId: 0651acf1e582a4d2)
    #1 0x7f8ff22ad334 in std::char_traits<char>::length(char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/char_traits.h:399:9
    llvm#2 0x7f8ff22a34a0 in llvm::StringRef::StringRef(char const*) /home/rjoshi/upstream-llvm-second/llvm-project/llvm/include/llvm/ADT/StringRef.h:96:33
    llvm#3 0x7f8ff28ca184 in _ZZL25lookupLLVMIntrinsicByNameN4llvm8ArrayRefIjEENS_9StringRefES2_ENK3$_0clIjPKcEEDaT_T0_ upstream-llvm-second/llvm-project/llvm/lib/IR/Intrinsics.cpp:673:18
```
dmpots pushed a commit that referenced this pull request Sep 9, 2025
@thurstond
Revert "[MLIR][XeGPU] Scattered ops sg-to-wi distribution" (llvm#156761)
c1cc9d2 
Reverts llvm#154949 due to suspected buildbot breakage
(https://lab.llvm.org/buildbot/#/builders/55/builds/16630/steps/11/logs/stdio).
Previously commented on the original pull request:
llvm#154949 (comment)

```
******************** TEST 'MLIR :: Dialect/XeGPU/subgroup-distribute.mlir' FAILED ********************
...
# | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
# | Stack dump:
# | 0.	Program arguments: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/mlir-opt -xegpu-subgroup-distribute -allow-unregistered-dialect -canonicalize -cse -split-input-file /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/test/Dialect/XeGPU/subgroup-distribute.mlir
# |  #0 0x0000c0af4b066df0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:834:13
# |  #1 0x0000c0af4b060e20 llvm::sys::RunSignalHandlers() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Signals.cpp:105:18
# |  llvm#2 0x0000c0af4b0691b4 SignalHandler(int, siginfo_t*, void*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:426:38
# |  llvm#3 0x0000ee25a3dcb8f8 (linux-vdso.so.1+0x8f8)
# |  llvm#4 0x0000ee25a36c7608 (/lib/aarch64-linux-gnu/libc.so.6+0x87608)
# |  llvm#5 0x0000ee25a367cb3c raise (/lib/aarch64-linux-gnu/libc.so.6+0x3cb3c)
# |  llvm#6 0x0000ee25a3667e00 abort (/lib/aarch64-linux-gnu/libc.so.6+0x27e00)
# |  llvm#7 0x0000c0af4ae7e4b0 __sanitizer::Atexit(void (*)()) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:168:10
# |  llvm#8 0x0000c0af4ae7c354 __sanitizer::Die() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:52:5
# |  llvm#9 0x0000c0af4ae66a30 Unlock /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_mutex.h:250:16
# | llvm#10 0x0000c0af4ae66a30 ~GenericScopedLock /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_mutex.h:386:51
# | llvm#11 0x0000c0af4ae66a30 __hwasan::ScopedReport::~ScopedReport() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:54:5
# | llvm#12 0x0000c0af4ae661b8 __hwasan::(anonymous namespace)::BaseReport::~BaseReport() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:477:7
# | llvm#13 0x0000c0af4ae63f5c __hwasan::ReportTagMismatch(__sanitizer::StackTrace*, unsigned long, unsigned long, bool, bool, unsigned long*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:1094:1
# | llvm#14 0x0000c0af4ae4f8e0 Destroy /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common.h:532:31
# | llvm#15 0x0000c0af4ae4f8e0 ~InternalMmapVector /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common.h:642:56
# | llvm#16 0x0000c0af4ae4f8e0 __hwasan::HandleTagMismatch(__hwasan::AccessInfo, unsigned long, unsigned long, void*, unsigned long*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan.cpp:245:1
# | llvm#17 0x0000c0af4ae51e8c __hwasan_tag_mismatch4 /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan.cpp:764:1
# | llvm#18 0x0000c0af4ae67b30 __interception::InterceptFunction(char const*, unsigned long*, unsigned long, unsigned long) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/interception/interception_linux.cpp:60:0
# | llvm#19 0x0000c0af5641cd24 getNumResults /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:404:37
# | llvm#20 0x0000c0af5641cd24 getOpResultImpl /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:1010:5
# | llvm#21 0x0000c0af5641cd24 getResult /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:407:54
# | llvm#22 0x0000c0af5641cd24 mlir::OpTrait::detail::MultiResultTraitBase<mlir::gpu::WarpExecuteOnLane0Op, mlir::OpTrait::VariadicResults>::getResult(unsigned int) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/OpDefinition.h:638:62
# | llvm#23 0x0000c0af56426b60 getType /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Value.h:63:33
# | llvm#24 0x0000c0af56426b60 getType /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Value.h:105:39
# | llvm#25 0x0000c0af56426b60 (anonymous namespace)::LoadDistribution::matchAndRewrite(mlir::gpu::WarpExecuteOnLane0Op, mlir::PatternRewriter&) const /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/lib/Dialect/XeGPU/Transforms/XeGPUSubgroupDistribute.cpp:991:55
...
```
dmpots pushed a commit that referenced this pull request Sep 9, 2025
@ellishg
[CodeGen][test][NFC] Refactor ObjC attribute tests (llvm#156519)
eee7211 
Some downstream work broke these tests because the attribute number
changed. Refactor these tests to be more resilient in the face of
changes like this

* `instrument-objc-method.m`
* `#1` was never checked, I think it was trying to check that
`__cyg_profile_func_enter` was not used, so I added
`--implicit-check-not="__cyg_profile_func_enter"`
  * Use `[[#ATTR:]]` so the test doesn't fail if the number changes
* `address-safety-attr.mm`
* Check attributes in `Function Attrs:` so it's independent of the
attribute number
dmpots pushed a commit that referenced this pull request Sep 17, 2025
@rez5427 @Yui5427
@arsenm @RKSimon
[DAGCombiner] add fold (xor (smin(x, C), C)) and fold (xor (smax(x, C…
6aab826 
…), C)) (llvm#155141)

Hi, I compared the following LLVM IR with GCC and Clang, and there is a small difference between the two. The LLVM IR is:
```
define i64 @test_smin_neg_one(i64 %a) {
  %1 = tail call i64 @llvm.smin.i64(i64 %a, i64 -1)
  %retval.0 = xor i64 %1, -1
  ret i64 %retval.0
}
```
GCC generates:
```
	cmp	x0, 0
	csinv	x0, xzr, x0, ge
	ret
```
Clang generates:
```
	cmn	x0, #1
	csinv	x8, x0, xzr, lt
	mvn	x0, x8
	ret
```
Clang keeps flipping x0 through x8 unnecessarily.
So I added the following folds to DAGCombiner:
fold (xor (smax(x, C), C)) -> select (x > C), xor(x, C), 0
fold (xor (smin(x, C), C)) -> select (x < C), xor(x, C), 0

alive2: https://alive2.llvm.org/ce/z/gffoir

---------

Co-authored-by: Yui5427 <[email protected]>
Co-authored-by: Matt Arsenault <[email protected]>
Co-authored-by: Simon Pilgrim <[email protected]>
dmpots pushed a commit that referenced this pull request Sep 17, 2025
@boomanaiden154
Revert "[libc++] Optimize __hash_table::erase(iterator, iterator) (#1… (
acc3a62 
llvm#158769)

…52471)"

This reverts commit e4eccd6.

This was causing ASan failures in some situations involving unordered
multimap containers. Details and a reproducer were posted on the
original PR (llvm#152471).
dmpots pushed a commit that referenced this pull request Oct 2, 2025
@barsolo2000
[lldb][GPU] Fix bug where we handle GPUActions multiple times (llvm#48)
104475a 
There is a bug that happens when you connect to the server where target list shows:
```
(lldb) target list
Current targets:
  target #0: /data/users/peix/llvm/gpu/build/Debug/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=622763, state=stopped )
  target #1: <none> ( arch=amdgcn-amd-amdhsa--gfx942, platform=host, pid=1, state=stopped )
* target llvm#2: <none> ( platform=host, state=unloaded )
```

The workflow: 
Process Launch -> initial stop (lldb always stops at launch) -> server gets notified -> 
server decide to send GPU actions in NativeProcessIsStopping() -> ready is returning true in ReadyToSendConnectionRequest -> 
Client is receiving the stop packet (our first process, GPU target created) ->  m_last_stop_packet = response (contains GPUactions) ->
LLDB calls RefreshStateAfterStop() (normal behavior) -> m_last_stop_packet is True so we reprocess the same packet -> 
SetThreadStopInfo(*m_last_stop_packet) -> Second Processing of Same GPU-Actions -> ParsePairs() extracts SAME: key="gpu-actions" ->
HandleGPUActions called for the second time -> HandleConnectionRequest() -> Tries to create SECOND GPU target. 

The two calls originate from this code:
https://github.com/clayborg/llvm-project/blob/llvm-server-plugins/lldb/source/Target/Process.cpp#L3276C1-L3291C6

The call on line 3267 to DoConnectRemote leads to a call to SetThreadStopInfo, which then calls HandleGPUActions.

Then the call on line 3289 to HandlePrivateEvent again leads to a call to SetTheadStopInfo (via RefreshStateAfterStop), which then calls HandleGPUActions for the same set of actions.

my fix is that the original stop packet (with GPU actions) is still cached in `m_last_stop_packet`, but we create a copy of the cached packet and strip the gpu-actions. 

---------

Co-authored-by: Bar Soloveychik <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@dmpots