Skip to content
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

Patch 9 #4

Merged
merged 2 commits into from
Jul 22, 2021
Merged

Patch 9 #4

merged 2 commits into from
Jul 22, 2021

Conversation

AZero13
Copy link
Owner

@AZero13 AZero13 commented Jul 22, 2021

No description provided.

AZero13 added 2 commits July 21, 2021 20:32
@AZero13
Update strchr.cpp
29eb636
@AZero13
Add explicit cast (#3)
6c78d3b 
We need to have the most efficient c++ casting
@AZero13 AZero13 merged commit b979477 into patch-10 Jul 22, 2021
AZero13 added a commit that referenced this pull request Jul 22, 2021
@AZero13
Patch 10 (#5)
0814cf1 
* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 11 (#8)
9cb0f64 
* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 12 (#9)
9655562 
* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 13 (#10)
c46aa2a 
* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 12 (#11)
fafe31d 
* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 13 (#12)
d5c4fee 
* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 13 (#13)
04796df 
* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 14 (#14)
a4f9513 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 14 (#15)
b2f08e5 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp
AZero13 added a commit that referenced this pull request Jul 23, 2021
@AZero13
Patch 14 (#16)
b722387 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#17)
befcce6 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#18)
888e479 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#19)
f3d938f 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#20)
b1f8b72 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#22)
4599a1a 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#23)
1d8f73a 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#24)
38a2c56 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#25)
c8e23cd 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#26)
1cfd201 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#27)
c44d91e 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#28)
d5ae03b 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 25, 2021
@AZero13
Patch 14 (#30)
4960b28 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 26, 2021
@AZero13
Patch 14 (#31)
77e0e9c 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

* format

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 26, 2021
@AZero13
Patch 14 (#33)
346d2ef 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

* format

* fix

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 26, 2021
@AZero13
Patch 14 (#34)
26c2244 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

* format

* fix

* z

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 26, 2021
@AZero13
Patch 14 (#35)
f7567e5 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

* format

* fix

* z

* OK

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Jul 26, 2021
@AZero13
Patch 14 (#36)
ba905c9 
* Update README.md

* Patch 13 (#13)

* Update README.md

* Patch 12 (#11)

* Update README.md

* Patch 13 (#10)

* Update README.md

* Patch 12 (#9)

* Update memchr.cpp

* Patch 10 (#6)

* Optimize string functions

* Update string_utils.h

* Update memrchr.cpp

* Patch 11 (#8)

* Update README.md

* Patch 10 (#5)

* Update CMakeLists.txt

* Patch 9 (#4)

* Update strchr.cpp

* Add explicit cast (#3)

We need to have the most efficient c++ casting

* Update strchr.cpp

* Update CMakeLists.txt

* Update strrchr.cpp

* Update README.md

* Update string_utils.h

* Update string_utils.h

* Update memchr.cpp

* Update README.md

* Update string_utils.h

* Update README.md

* Update README.md

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update memmove.cpp

* Update memcpy.cpp

* Update memmove.cpp

* Update README.md

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Update strcpy.cpp

* Update strcpy.cpp

* Update memmove.cpp

* Fix

* Fix

* Update elements.h

* Update elements.h

* Oh

* j

* D

* Update memcpy.cpp

* fix

* Update memmove.cpp

* No except time

* Update strspn.cpp

* Update memmove.cpp

* F

* Update elements.h

* format

* fix

* z

* OK

* d

* e

* X

* Update memset_utils.h

* Update utils.h

* Update string_utils.h

* k

* m

Co-authored-by: Radical Dweamer <83354299+RadiD234@users.noreply.github.com>
AZero13 added a commit that referenced this pull request Mar 11, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
1fb69eb 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Mar 12, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
7b6cca2 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Mar 14, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
5901c3e 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Mar 27, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
a3d675b 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Mar 28, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
168ac85 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 2, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
7df5744 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 2, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
ad1712f 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 2, 2024
@AZero13
[Thumb1] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
9ab332a 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 2, 2024
@AZero13
[Thumb] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
50c0465 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 2, 2024
@AZero13
[Thumb] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi'
675922e 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can in r10 or r11, or r12.
AZero13 added a commit that referenced this pull request Apr 5, 2024
@AZero13
[Thumb] Resolve FIXME: Use 'mov hi, $src; mov $dst, hi' (llvm#81908)
c5d000b 
Consider the following:

        ldr     r0, [r4]
        ldr     r7, [r0, #4]
        cmp     r7, r3
        bhi     .LBB0_6
        cmp     r0, r2
        push    {r0}
        pop     {r4}
        bne     .LBB0_3
        movs    r0, r6
        pop     {r4, r5, r6, r7}
        pop     {r1}
        bx      r1

Here is a snippet of the generated THUMB1 code of the K&R malloc
function that clang currently compiles to.

push    {r0} ends up being popped to pop {r4}.

movs r4, r0 would destroy the flags set by cmp right above.

The compiler has no alternative in this case, except one:
the only alternative is to transfer through a high register.

However, it seems like LLVM does not consider that this is a valid
approach, even though it is a free clobbering a high register.

This patch addresses the FIXME so the compiler can do that when it can
in r10 or r11, or r12.
AZero13 pushed a commit that referenced this pull request May 8, 2024
@sdkrystian
[Clang][Sema] Improve support for explicit specializations of constra…
34ae226 
…ined member functions & member function templates (llvm#88963)

Consider the following snippet from the discussion of CWG2847 on the core reflector:
```
template<typename T>
concept C = sizeof(T) <= sizeof(long);

template<typename T>
struct A 
{
    template<typename U>
    void f(U) requires C<U>; // #1, declares a function template 

    void g() requires C<T>; // #2, declares a function

    template<>
    void f(char);  // #3, an explicit specialization of a function template that declares a function
};

template<>
template<typename U>
void A<short>::f(U) requires C<U>; // #4, an explicit specialization of a function template that declares a function template

template<>
template<>
void A<int>::f(int); // #5, an explicit specialization of a function template that declares a function

template<>
void A<long>::g(); // #6, an explicit specialization of a function that declares a function
```

A number of problems exist:
- Clang rejects `#4` because the trailing _requires-clause_ has `U`
substituted with the wrong template parameter depth when
`Sema::AreConstraintExpressionsEqual` is called to determine whether it
matches the trailing _requires-clause_ of the implicitly instantiated
function template.
- Clang rejects `#5` because the function template specialization
instantiated from `A<int>::f` has a trailing _requires-clause_, but `#5`
does not (nor can it have one as it isn't a templated function).
- Clang rejects `#6` for the same reasons it rejects `#5`.

This patch resolves these issues by making the following changes:
- To fix `#4`, `Sema::AreConstraintExpressionsEqual` is passed
`FunctionTemplateDecl`s when comparing the trailing _requires-clauses_
of `#4` and the function template instantiated from `#1`.
- To fix `#5` and `#6`, the trailing _requires-clauses_ are not compared
for explicit specializations that declare functions.

In addition to these changes, `CheckMemberSpecialization` now considers
constraint satisfaction/constraint partial ordering when determining
which member function is specialized by an explicit specialization of a
member function for an implicit instantiation of a class template (we
previously would select the first function that has the same type as the
explicit specialization). With constraints taken under consideration, we
match EDG's behavior for these declarations.
AZero13 pushed a commit that referenced this pull request May 16, 2024
@stbergmann
Avoid partial munmap (llvm#92109)
4688df6 
...which caused issues like

> ==42==ERROR: AddressSanitizer failed to deallocate 0x32 (50) bytes at
address 0x117e0000 (error code: 28)
> ==42==Cannot dump memory map on emscriptenAddressSanitizer: CHECK
failed: sanitizer_common.cpp:81 "((0 && "unable to unmmap")) != (0)"
(0x0, 0x0) (tid=288045824)
> #0 0x14f73b0c in __asan::CheckUnwind()+0x14f73b0c
(this.program+0x14f73b0c)
> #1 0x14f8a3c2 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)+0x14f8a3c2
(this.program+0x14f8a3c2)
> #2 0x14f7d6e1 in __sanitizer::ReportMunmapFailureAndDie(void*,
unsigned long, int, bool)+0x14f7d6e1 (this.program+0x14f7d6e1)
> #3 0x14f81fbd in __sanitizer::UnmapOrDie(void*, unsigned
long)+0x14f81fbd (this.program+0x14f81fbd)
> #4 0x14f875df in __sanitizer::SuppressionContext::ParseFromFile(char
const*)+0x14f875df (this.program+0x14f875df)
> #5 0x14f74eab in __asan::InitializeSuppressions()+0x14f74eab
(this.program+0x14f74eab)
> #6 0x14f73a1a in __asan::AsanInitInternal()+0x14f73a1a
(this.program+0x14f73a1a)

when trying to use an ASan suppressions file under Emscripten: Even
though it would be considered OK by SUSv4, the Emscripten runtime states
"We don't support partial munmapping" (see

<emscripten-core/emscripten@f4115eb>
"Implement MAP_ANONYMOUS on top of malloc in STANDALONE_WASM mode
(llvm#16289)").

Co-authored-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
AZero13 pushed a commit that referenced this pull request May 16, 2024
@gribozavr
Revert "[LoopUnroll] Clamp PartialThreshold for large LoopMicroOpBuff…
83974a4 
…erSize (llvm#67657)"

This reverts commit f0b3654.

This commit triggers UB by reading an uninitialized variable.

`UP.PartialThreshold` is used uninitialized in `getUnrollingPreferences()` when
it is called from `LoopVectorizationPlanner::executePlan()`. In this case the
`UP` variable is created on the stack and its fields are not initialized.

```
==8802==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x557c0b081b99 in llvm::BasicTTIImplBase<llvm::X86TTIImpl>::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) llvm-project/llvm/include/llvm/CodeGen/BasicTTIImpl.h
    #1 0x557c0b07a40c in llvm::TargetTransformInfo::Model<llvm::X86TTIImpl>::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) llvm-project/llvm/include/llvm/Analysis/TargetTransformInfo.h:2277:17
    #2 0x557c0f5d69ee in llvm::TargetTransformInfo::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) const llvm-project/llvm/lib/Analysis/TargetTransformInfo.cpp:387:19
    #3 0x557c0e6b96a0 in llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool, llvm::DenseMap<llvm::SCEV const*, llvm::Value*, llvm::DenseMapInfo<llvm::SCEV const*, void>, llvm::detail::DenseMapPair<llvm::SCEV const*, llvm::Value*>> const*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7624:7
    #4 0x557c0e6e4b63 in llvm::LoopVectorizePass::processLoop(llvm::Loop*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10253:13
    #5 0x557c0e6f2429 in llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AssumptionCache&, llvm::LoopAccessInfoManager&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10344:30
    #6 0x557c0e6f2f97 in llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10383:9

[...]

  Uninitialized value was created by an allocation of 'UP' in the stack frame
    #0 0x557c0e6b961e in llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool, llvm::DenseMap<llvm::SCEV const*, llvm::Value*, llvm::DenseMapInfo<llvm::SCEV const*, void>, llvm::detail::DenseMapPair<llvm::SCEV const*, llvm::Value*>> const*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7623:3
```
AZero13 pushed a commit that referenced this pull request Jul 4, 2024
@pifon2a
Revert "[mlir][loops] Reland Refactor LoopFuseSiblingOp and support p…
97a2bd8 
…arallel fusion llvm#94391 (llvm#97607)"

This reverts commit edbc0e3.

Reason for rollback. ASAN complains about this PR:

==4320==ERROR: AddressSanitizer: heap-use-after-free on address 0x502000006cd8 at pc 0x55e2978d63cf bp 0x7ffe6431c2b0 sp 0x7ffe6431c2a8
READ of size 8 at 0x502000006cd8 thread T0
    #0 0x55e2978d63ce in map<llvm::MutableArrayRef<mlir::BlockArgument> &, llvm::MutableArrayRef<mlir::BlockArgument>, nullptr> mlir/include/mlir/IR/IRMapping.h:40:11
    #1 0x55e2978d63ce in mlir::createFused(mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface, mlir::RewriterBase&, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)>, llvm::function_ref<void (mlir::RewriterBase&, mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface&, mlir::IRMapping)>) mlir/lib/Interfaces/LoopLikeInterface.cpp:156:11
    #2 0x55e2952a614b in mlir::fuseIndependentSiblingForLoops(mlir::scf::ForOp, mlir::scf::ForOp, mlir::RewriterBase&) mlir/lib/Dialect/SCF/Utils/Utils.cpp:1398:43
    #3 0x55e291480c6f in mlir::transform::LoopFuseSiblingOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp:482:17
    #4 0x55e29149ed5e in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::LoopFuseSiblingOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56
    #5 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14
    #6 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48
    #7 0x55e294646a8d in applySequenceBlock(mlir::Block&, mlir::transform::FailurePropagationMode, mlir::transform::TransformState&, mlir::transform::TransformResults&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:1788:15
    #8 0x55e29464f927 in mlir::transform::NamedSequenceOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:2155:10
    #9 0x55e2945d28ee in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::NamedSequenceOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56
    #10 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14
    #11 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48
    #12 0x55e2974a5fe2 in mlir::transform::applyTransforms(mlir::Operation*, mlir::transform::TransformOpInterface, mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>> const&, mlir::transform::TransformOptions const&, bool) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:2016:16
    #13 0x55e2945888d7 in mlir::transform::applyTransformNamedSequence(mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>>, mlir::transform::TransformOpInterface, mlir::ModuleOp, mlir::transform::TransformOptions const&) mlir/lib/Dialect/Transform/Transforms/TransformInterpreterUtils.cpp:234:10
    #14 0x55e294582446 in (anonymous namespace)::InterpreterPass::runOnOperation() mlir/lib/Dialect/Transform/Transforms/InterpreterPass.cpp:147:16
    #15 0x55e2978e93c6 in operator() mlir/lib/Pass/Pass.cpp:527:17
    #16 0x55e2978e93c6 in void llvm::function_ref<void ()>::callback_fn<mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_1>(long) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    #17 0x55e2978e207a in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    #18 0x55e2978e207a in executeAction<mlir::PassExecutionAction, mlir::Pass &> mlir/include/mlir/IR/MLIRContext.h:275:7
    #19 0x55e2978e207a in mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) mlir/lib/Pass/Pass.cpp:521:21
    #20 0x55e2978e5fbf in runPipeline mlir/lib/Pass/Pass.cpp:593:16
    #21 0x55e2978e5fbf in mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) mlir/lib/Pass/Pass.cpp:904:10
    #22 0x55e2978e5b65 in mlir::PassManager::run(mlir::Operation*) mlir/lib/Pass/Pass.cpp:884:60
    #23 0x55e291ebb460 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:408:17
    #24 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9
    #25 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12
    #26 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    #27 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    #28 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16
    #29 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3
    #30 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3
    #31 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3
    #32 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10
    #33 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14
    #34 0x55e291eb15f8 in mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:605:10
    #35 0x55e29130d1be in main mlir/tools/mlir-opt/mlir-opt.cpp:311:33
    #36 0x7fbcf3fff3d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94)
    #37 0x55e2912365a9 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120

0x502000006cd8 is located 8 bytes inside of 16-byte region [0x502000006cd0,0x502000006ce0)
freed by thread T0 here:
    #0 0x55e29130b7e2 in operator delete(void*, unsigned long) compiler-rt/lib/asan/asan_new_delete.cpp:155:3
    #1 0x55e2979eb657 in __libcpp_operator_delete<void *, unsigned long>
    #2 0x55e2979eb657 in __do_deallocate_handle_size<>
    #3 0x55e2979eb657 in __libcpp_deallocate
    #4 0x55e2979eb657 in deallocate
    #5 0x55e2979eb657 in deallocate
    #6 0x55e2979eb657 in operator()
    #7 0x55e2979eb657 in ~vector
    #8 0x55e2979eb657 in mlir::Block::~Block() mlir/lib/IR/Block.cpp:24:1
    #9 0x55e2979ebc17 in deleteNode llvm/include/llvm/ADT/ilist.h:42:39
    #10 0x55e2979ebc17 in erase llvm/include/llvm/ADT/ilist.h:205:5
    #11 0x55e2979ebc17 in erase llvm/include/llvm/ADT/ilist.h:209:39
    #12 0x55e2979ebc17 in mlir::Block::erase() mlir/lib/IR/Block.cpp:67:28
    #13 0x55e297aef978 in mlir::RewriterBase::eraseBlock(mlir::Block*) mlir/lib/IR/PatternMatch.cpp:245:10
    #14 0x55e297af0563 in mlir::RewriterBase::inlineBlockBefore(mlir::Block*, mlir::Block*, llvm::ilist_iterator<llvm::ilist_detail::node_options<mlir::Operation, false, false, void, false, void>, false, false>, mlir::ValueRange) mlir/lib/IR/PatternMatch.cpp:331:3
    #15 0x55e297af06d8 in mlir::RewriterBase::mergeBlocks(mlir::Block*, mlir::Block*, mlir::ValueRange) mlir/lib/IR/PatternMatch.cpp:341:3
    #16 0x55e297036608 in mlir::scf::ForOp::replaceWithAdditionalYields(mlir::RewriterBase&, mlir::ValueRange, bool, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)> const&) mlir/lib/Dialect/SCF/IR/SCF.cpp:575:12
    #17 0x55e2970673ca in mlir::detail::LoopLikeOpInterfaceInterfaceTraits::Model<mlir::scf::ForOp>::replaceWithAdditionalYields(mlir::detail::LoopLikeOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::RewriterBase&, mlir::ValueRange, bool, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)> const&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Interfaces/LoopLikeInterface.h.inc:658:56
    #18 0x55e2978d5feb in replaceWithAdditionalYields blaze-out/k8-opt-asan/bin/mlir/include/mlir/Interfaces/LoopLikeInterface.cpp.inc:105:14
    #19 0x55e2978d5feb in mlir::createFused(mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface, mlir::RewriterBase&, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)>, llvm::function_ref<void (mlir::RewriterBase&, mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface&, mlir::IRMapping)>) mlir/lib/Interfaces/LoopLikeInterface.cpp:135:14
    #20 0x55e2952a614b in mlir::fuseIndependentSiblingForLoops(mlir::scf::ForOp, mlir::scf::ForOp, mlir::RewriterBase&) mlir/lib/Dialect/SCF/Utils/Utils.cpp:1398:43
    #21 0x55e291480c6f in mlir::transform::LoopFuseSiblingOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp:482:17
    #22 0x55e29149ed5e in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::LoopFuseSiblingOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56
    #23 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14
    #24 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48
    #25 0x55e294646a8d in applySequenceBlock(mlir::Block&, mlir::transform::FailurePropagationMode, mlir::transform::TransformState&, mlir::transform::TransformResults&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:1788:15
    #26 0x55e29464f927 in mlir::transform::NamedSequenceOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:2155:10
    #27 0x55e2945d28ee in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::NamedSequenceOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56
    #28 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14
    #29 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48
    #30 0x55e2974a5fe2 in mlir::transform::applyTransforms(mlir::Operation*, mlir::transform::TransformOpInterface, mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>> const&, mlir::transform::TransformOptions const&, bool) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:2016:16
    #31 0x55e2945888d7 in mlir::transform::applyTransformNamedSequence(mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>>, mlir::transform::TransformOpInterface, mlir::ModuleOp, mlir::transform::TransformOptions const&) mlir/lib/Dialect/Transform/Transforms/TransformInterpreterUtils.cpp:234:10
    #32 0x55e294582446 in (anonymous namespace)::InterpreterPass::runOnOperation() mlir/lib/Dialect/Transform/Transforms/InterpreterPass.cpp:147:16
    #33 0x55e2978e93c6 in operator() mlir/lib/Pass/Pass.cpp:527:17
    #34 0x55e2978e93c6 in void llvm::function_ref<void ()>::callback_fn<mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_1>(long) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    #35 0x55e2978e207a in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    #36 0x55e2978e207a in executeAction<mlir::PassExecutionAction, mlir::Pass &> mlir/include/mlir/IR/MLIRContext.h:275:7
    #37 0x55e2978e207a in mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) mlir/lib/Pass/Pass.cpp:521:21
    #38 0x55e2978e5fbf in runPipeline mlir/lib/Pass/Pass.cpp:593:16
    #39 0x55e2978e5fbf in mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) mlir/lib/Pass/Pass.cpp:904:10
    #40 0x55e2978e5b65 in mlir::PassManager::run(mlir::Operation*) mlir/lib/Pass/Pass.cpp:884:60
    #41 0x55e291ebb460 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:408:17
    llvm#42 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9
    llvm#43 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12
    llvm#44 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    llvm#45 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    llvm#46 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16
    llvm#47 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3
    llvm#48 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3
    llvm#49 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3
    llvm#50 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10
    llvm#51 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14

previously allocated by thread T0 here:
    #0 0x55e29130ab5d in operator new(unsigned long) compiler-rt/lib/asan/asan_new_delete.cpp:86:3
    #1 0x55e2979ed5d4 in __libcpp_operator_new<unsigned long>
    #2 0x55e2979ed5d4 in __libcpp_allocate
    #3 0x55e2979ed5d4 in allocate
    #4 0x55e2979ed5d4 in __allocate_at_least<std::__u::allocator<mlir::BlockArgument> >
    #5 0x55e2979ed5d4 in __split_buffer
    #6 0x55e2979ed5d4 in mlir::BlockArgument* std::__u::vector<mlir::BlockArgument, std::__u::allocator<mlir::BlockArgument>>::__push_back_slow_path<mlir::BlockArgument const&>(mlir::BlockArgument const&)
    #7 0x55e2979ec0f2 in push_back
    #8 0x55e2979ec0f2 in mlir::Block::addArgument(mlir::Type, mlir::Location) mlir/lib/IR/Block.cpp:154:13
    #9 0x55e29796e457 in parseRegionBody mlir/lib/AsmParser/Parser.cpp:2172:34
    #10 0x55e29796e457 in (anonymous namespace)::OperationParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:2121:7
    #11 0x55e29796b25e in (anonymous namespace)::CustomOpAsmParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1785:16
    #12 0x55e297035742 in mlir::scf::ForOp::parse(mlir::OpAsmParser&, mlir::OperationState&) mlir/lib/Dialect/SCF/IR/SCF.cpp:521:14
    #13 0x55e291322c18 in llvm::ParseResult llvm::detail::UniqueFunctionBase<llvm::ParseResult, mlir::OpAsmParser&, mlir::OperationState&>::CallImpl<llvm::ParseResult (*)(mlir::OpAsmParser&, mlir::OperationState&)>(void*, mlir::OpAsmParser&, mlir::OperationState&) llvm/include/llvm/ADT/FunctionExtras.h:220:12
    #14 0x55e29795bea3 in operator() llvm/include/llvm/ADT/FunctionExtras.h:384:12
    #15 0x55e29795bea3 in callback_fn<llvm::unique_function<llvm::ParseResult (mlir::OpAsmParser &, mlir::OperationState &)> > llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    #16 0x55e29795bea3 in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    #17 0x55e29795bea3 in parseOperation mlir/lib/AsmParser/Parser.cpp:1521:9
    #18 0x55e29795bea3 in parseCustomOperation mlir/lib/AsmParser/Parser.cpp:2017:19
    #19 0x55e29795bea3 in (anonymous namespace)::OperationParser::parseOperation() mlir/lib/AsmParser/Parser.cpp:1174:10
    #20 0x55e297971d20 in parseBlockBody mlir/lib/AsmParser/Parser.cpp:2296:9
    #21 0x55e297971d20 in (anonymous namespace)::OperationParser::parseBlock(mlir::Block*&) mlir/lib/AsmParser/Parser.cpp:2226:12
    #22 0x55e29796e4f5 in parseRegionBody mlir/lib/AsmParser/Parser.cpp:2184:7
    #23 0x55e29796e4f5 in (anonymous namespace)::OperationParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:2121:7
    #24 0x55e29796b25e in (anonymous namespace)::CustomOpAsmParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1785:16
    #25 0x55e29796b2cf in (anonymous namespace)::CustomOpAsmParser::parseOptionalRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1796:12
    #26 0x55e2978d89ff in mlir::function_interface_impl::parseFunctionOp(mlir::OpAsmParser&, mlir::OperationState&, bool, mlir::StringAttr, llvm::function_ref<mlir::Type (mlir::Builder&, llvm::ArrayRef<mlir::Type>, llvm::ArrayRef<mlir::Type>, mlir::function_interface_impl::VariadicFlag, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>&)>, mlir::StringAttr, mlir::StringAttr) mlir/lib/Interfaces/FunctionImplementation.cpp:232:14
    #27 0x55e2969ba41d in mlir::func::FuncOp::parse(mlir::OpAsmParser&, mlir::OperationState&) mlir/lib/Dialect/Func/IR/FuncOps.cpp:203:10
    #28 0x55e291322c18 in llvm::ParseResult llvm::detail::UniqueFunctionBase<llvm::ParseResult, mlir::OpAsmParser&, mlir::OperationState&>::CallImpl<llvm::ParseResult (*)(mlir::OpAsmParser&, mlir::OperationState&)>(void*, mlir::OpAsmParser&, mlir::OperationState&) llvm/include/llvm/ADT/FunctionExtras.h:220:12
    #29 0x55e29795bea3 in operator() llvm/include/llvm/ADT/FunctionExtras.h:384:12
    #30 0x55e29795bea3 in callback_fn<llvm::unique_function<llvm::ParseResult (mlir::OpAsmParser &, mlir::OperationState &)> > llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    #31 0x55e29795bea3 in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    #32 0x55e29795bea3 in parseOperation mlir/lib/AsmParser/Parser.cpp:1521:9
    #33 0x55e29795bea3 in parseCustomOperation mlir/lib/AsmParser/Parser.cpp:2017:19
    #34 0x55e29795bea3 in (anonymous namespace)::OperationParser::parseOperation() mlir/lib/AsmParser/Parser.cpp:1174:10
    #35 0x55e297959b78 in parse mlir/lib/AsmParser/Parser.cpp:2725:20
    #36 0x55e297959b78 in mlir::parseAsmSourceFile(llvm::SourceMgr const&, mlir::Block*, mlir::ParserConfig const&, mlir::AsmParserState*, mlir::AsmParserCodeCompleteContext*) mlir/lib/AsmParser/Parser.cpp:2785:41
    #37 0x55e29790d5c2 in mlir::parseSourceFile(std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::Block*, mlir::ParserConfig const&, mlir::LocationAttr*) mlir/lib/Parser/Parser.cpp:46:10
    #38 0x55e291ebbfe2 in parseSourceFile<mlir::ModuleOp, const std::__u::shared_ptr<llvm::SourceMgr> &> mlir/include/mlir/Parser/Parser.h:159:14
    #39 0x55e291ebbfe2 in parseSourceFile<mlir::ModuleOp> mlir/include/mlir/Parser/Parser.h:189:10
    #40 0x55e291ebbfe2 in mlir::parseSourceFileForTool(std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::ParserConfig const&, bool) mlir/include/mlir/Tools/ParseUtilities.h:31:12
    #41 0x55e291ebb263 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:383:33
    llvm#42 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9
    llvm#43 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12
    llvm#44 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
    llvm#45 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
    llvm#46 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16
    llvm#47 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3
    llvm#48 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3
    llvm#49 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3
    llvm#50 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10
    llvm#51 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14
    llvm#52 0x55e291eb15f8 in mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:605:10
    llvm#53 0x55e29130d1be in main mlir/tools/mlir-opt/mlir-opt.cpp:311:33
    llvm#54 0x7fbcf3fff3d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94)
    llvm#55 0x55e2912365a9 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120

SUMMARY: AddressSanitizer: heap-use-after-free mlir/include/mlir/IR/IRMapping.h:40:11 in map<llvm::MutableArrayRef<mlir::BlockArgument> &, llvm::MutableArrayRef<mlir::BlockArgument>, nullptr>
Shadow bytes around the buggy address:
  0x502000006a00: fa fa 00 fa fa fa 00 00 fa fa 00 fa fa fa 00 fa
  0x502000006a80: fa fa 00 fa fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x502000006b00: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 fa
  0x502000006b80: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa 00 00
  0x502000006c00: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fa
=>0x502000006c80: fa fa fd fa fa fa fd fd fa fa fd[fd]fa fa fd fd
  0x502000006d00: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x502000006d80: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x502000006e00: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa 00 fa
  0x502000006e80: fa fa 00 fa fa fa 00 00 fa fa 00 fa fa fa 00 fa
  0x502000006f00: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==4320==ABORTING
AZero13 pushed a commit that referenced this pull request Jul 8, 2024
@kendalharland
Fix flake in TestZerothFrame.py (llvm#96685)
4c23625 
This test is currently flaky on a local Windows amd64 build. The reason
is that it relies on the order of `process.threads` but this order is
nondeterministic:

If we print lldb's inputs and outputs while running, we can see that the
breakpoints are always being set correctly, and always being hit:

```sh
runCmd: breakpoint set -f "main.c" -l 2
output: Breakpoint 1: where = a.out`func_inner + 1 at main.c:2:9, address = 0x0000000140001001

runCmd: breakpoint set -f "main.c" -l 7
output: Breakpoint 2: where = a.out`main + 17 at main.c:7:5, address = 0x0000000140001021

runCmd: run
output: Process 52328 launched: 'C:\workspace\llvm-project\llvm\build\lldb-test-build.noindex\functionalities\unwind\zeroth_frame\TestZerothFrame.test_dwarf\a.out' (x86_64)
Process 52328 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ff68f6b1001 a.out`func_inner at main.c:2:9
   1    void func_inner() {
-> 2        int a = 1;  // Set breakpoint 1 here
                ^
   3    }
   4
   5    int main() {
   6        func_inner();
   7        return 0; // Set breakpoint 2 here
```

However, sometimes the backtrace printed in this test shows that the
process is stopped inside NtWaitForWorkViaWorkerFactory from
`ntdll.dll`:

```sh
Backtrace at the first breakpoint:
frame #0: 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
frame #1: 0x00007ffecc74585e ntdll.dll`RtlClearThreadWorkOnBehalfTicket + 862
frame #2: 0x00007ffecc3e257d kernel32.dll`BaseThreadInitThunk + 29
frame #3: 0x00007ffecc76af28 ntdll.dll`RtlUserThreadStart + 40
```

When this happens, the test fails with an assertion error that the
stopped thread's zeroth frame's current line number does not match the
expected line number. This is because the test is looking at the wrong
thread: `process.threads[0]`.

If we print the list of threads each time the test is run, we notice
that threads are sometimes in a different order, within
`process.threads`:

```sh
Thread 0: thread #4: tid = 0x9c38, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
Thread 1: thread #2: tid = 0xa950, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
Thread 2: thread #1: tid = 0xab18, 0x00007ff64bc81001 a.out`func_inner at main.c:2:9, stop reason = breakpoint 1.1
Thread 3: thread #3: tid = 0xc514, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20

Thread 0: thread #3: tid = 0x018c, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
Thread 1: thread #1: tid = 0x85c8, 0x00007ff7130c1001 a.out`func_inner at main.c:2:9, stop reason = breakpoint 1.1
Thread 2: thread #2: tid = 0xf344, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
Thread 3: thread #4: tid = 0x6a50, 0x00007ffecc7b3bf4 ntdll.dll`NtWaitForWorkViaWorkerFactory + 20
```

Use `self.thread()` to consistently select the correct thread, instead.

Co-authored-by: kendal <kendal@thebrowser.company>
AZero13 pushed a commit that referenced this pull request Aug 9, 2024
@MacDue @tru
[LSR] Fix matching vscale immediates (llvm#100080)
75642a0 
Somewhat confusingly a `SCEVMulExpr` is a `SCEVNAryExpr`, so can have
> 2 operands. Previously, the vscale immediate matching did not check
the number of operands of the `SCEVMulExpr`, so would ignore any
operands after the first two.

This led to incorrect codegen (and results) for ArmSME in IREE
(https://github.com/iree-org/iree), which sometimes addresses things
that are a `vscale * vscale` multiple away. The test added with this
change shows an example reduced from IREE. The second write should
be offset from the first `16 * vscale * vscale` (* 4 bytes), however,
previously LSR dropped the second vscale and instead offset the write by
`#4, mul vl`, which is an offset of `16 * vscale` (* 4 bytes).

(cherry picked from commit 7fad04e)
AZero13 pushed a commit that referenced this pull request Sep 6, 2024
@adrian-prantl
[lldb] Extend frame recognizers to hide frames from backtraces (llvm#…
f01f80c 
…104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but the
compiler/runtime itself. This patch introduces a user-extensible
mechanism that allows for these frames to be hidden from backtraces and
automatically skipped over when navigating the stack with `up` and
`down`.

This does not affect the numbering of frames, so `f <N>` will still
provide access to the hidden frames. The `bt` output will also print a
hint that frames have been hidden.

My primary motivation for this feature is to hide thunks in the Swift
programming language, but I'm including an example recognizer for
`std::function::operator()` that I wished for myself many times while
debugging LLDB.

rdar://126629381


Example output. (Yes, my proof-of-concept recognizer could hide even
more frames if we had a method that returned the function name without
the return type or I used something that isn't based off regex, but it's
really only meant as an example).

before:
```
(lldb) thread backtrace --filtered=false
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
    frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
    frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
    frame #3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12
    frame #4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10
    frame #5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12
    frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
    frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
    frame #8: 0x0000000183cdf154 dyld`start + 2476
(lldb) 
```

after

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
    frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
    frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
    frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
    frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
    frame #8: 0x0000000183cdf154 dyld`start + 2476
Note: Some frames were hidden by frame recognizers
```
AZero13 pushed a commit that referenced this pull request Sep 6, 2024
@ezhulenev
[orc] Fix asan error in RTDyldObjectLinkingLayer.cpp (llvm#106300)
c0ebc18 
`JITDylibSearchOrderResolver` local variable can be destroyed before
completion of all callbacks. Capture it together with `Deps` in
`OnEmitted` callback.

Original error:

```
==2035==ERROR: AddressSanitizer: stack-use-after-return on address 0x7bebfa155b70 at pc 0x7ff2a9a88b4a bp 0x7bec08d51980 sp 0x7bec08d51978
READ of size 8 at 0x7bebfa155b70 thread T87 (tf_xla-cpu-llvm)
    #0 0x7ff2a9a88b49 in operator() llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:58
    #1 0x7ff2a9a88b49 in __invoke<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:149:25
    #2 0x7ff2a9a88b49 in __call<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:224:5
    #3 0x7ff2a9a88b49 in operator() libcxx/include/__functional/function.h:210:12
    #4 0x7ff2a9a88b49 in void std::__u::__function::__policy_invoker<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr,
```
AZero13 pushed a commit that referenced this pull request Sep 6, 2024
@ezhulenev
Fix tsan race in PerfJITEventListener.cpp (llvm#106800)
d004ebc 
Static destructor can race with calls to notify and trigger tsan
warning.

```
WARNING: ThreadSanitizer: data race (pid=5787)
  Write of size 1 at 0x55bec9df8de8 by thread T23:
    #0 pthread_mutex_destroy [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1344](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1344&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12affb) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #1 __libcpp_recursive_mutex_destroy [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:91](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=91&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #2 std::__tsan::recursive_mutex::~recursive_mutex() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:52](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=52&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9)
    #3 ~SmartMutex [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:28](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=28&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #4 (anonymous namespace)::PerfJITEventListener::~PerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:65](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=65&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe)
    #5 cxa_at_exit_callback_installed_at(void*) [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:437](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=437&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b172cb9) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #6 llvm::JITEventListener::createPerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:496](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=496&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcad8f5) (BuildId: ff25ace8b17d9863348bb1759c47246c)
```
```
Previous atomic read of size 1 at 0x55bec9df8de8 by thread T192 (mutexes: write M0, write M1):
    #0 pthread_mutex_unlock [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1387](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1387&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12b6bb) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #1 __libcpp_recursive_mutex_unlock [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:87](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=87&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #2 std::__tsan::recursive_mutex::unlock() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:64](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=64&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589)
    #3 unlock [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:47](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=47&cl=669089572):16 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) (BuildId: ff25ace8b17d9863348bb1759c47246c)
    #4 ~lock_guard [third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h:39](third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h?l=39&cl=669089572):101 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968)
    #5 (anonymous namespace)::PerfJITEventListener::notifyObjectLoaded(unsigned long, llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo const&) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:290](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=290&cl=669089572):1 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968)
    #6 llvm::orc::RTDyldObjectLinkingLayer::onObjEmit(llvm::orc::MaterializationResponsibility&, llvm::object::OwningBinary<llvm::object::ObjectFile>, std::__tsan::unique_ptr<llvm::RuntimeDyld::MemoryManager, std::__tsan::default_delete<llvm::RuntimeDyld::MemoryManager>>, std::__tsan::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo, std::__tsan::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>, std::__tsan::unique_ptr<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>, std::__tsan::default_delete<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>>>, llvm::Error) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:386](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp?l=386&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bc404a8) (BuildId: ff25ace8b17d9863348bb1759c47246c)
```
AZero13 pushed a commit that referenced this pull request Sep 16, 2024
@rorth
[ASan] Disable InstallAtForkHandler on Linux/sparc64 (llvm#108542)
9b237b4 
When SPARC Asan testing is enabled by PR llvm#107405, many Linux/sparc64
tests just hang like
```
#0  0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6
#1  0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) ()
    at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766
#2  0x70107c90 in Wait ()
    at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35
#3  0x700f7cac in Lock ()
    at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196
#4  Lock ()
    at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98
#5  LockThreads ()
    at compiler-rt/lib/asan/asan_thread.cpp:489
#6  0x700e9c8c in __asan::BeforeFork() ()
    at compiler-rt/lib/asan/asan_posix.cpp:157
#7  0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
It turns out that this happens in tests using `internal_fork` (e.g.
invoking `llvm-symbolizer`): unlike most other Linux targets, which use
`clone`, Linux/sparc64 has to use `__fork` instead. While `clone`
doesn't trigger `pthread_atfork` handlers, `__fork` obviously does,
causing the hang.

To avoid this, this patch disables `InstallAtForkHandler` and lets the
ASan tests run to completion.

Tested on `sparc64-unknown-linux-gnu`.
AZero13 pushed a commit that referenced this pull request Oct 3, 2024
@Michael137
[lldb][TypeSystemClang] Add warning and defensive checks when ASTCont…
a5f3a2a 
…ext is not fully initialized (llvm#110481)

As this comment around target initialization implies:
```
  // This can be NULL if we don't know anything about the architecture or if
  // the target for an architecture isn't enabled in the llvm/clang that we
  // built
```

There are cases where we might fail to call `InitBuiltinTypes` when
creating the backing `ASTContext` for a `TypeSystemClang`. If that
happens, the builtins `QualType`s, e.g., `VoidPtrTy`/`IntTy`/etc., are
not initialized and dereferencing them as we do in
`GetBuiltinTypeForEncodingAndBitSize` (and other places) will lead to
nullptr-dereferences. Example backtrace:
```
(lldb) run
Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file Type.h, line 958.
Process 2680 stopped
* thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert
    frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) + 
liblldb.20.0.0git.dylib`DWARFASTParserClang::ParseObjCMethod(lldb_private::ObjCLanguage::MethodName const&, lldb_private::plugin::dwarf::DWARFDIE const&, lldb_private::CompilerType, ParsedDWARFTypeAttributes
, bool) (.cold.1):
->  0x10cdf3cdc <+0>:  stp    x29, x30, [sp, #-0x10]!
    0x10cdf3ce0 <+4>:  mov    x29, sp
    0x10cdf3ce4 <+8>:  adrp   x0, 545
    0x10cdf3ce8 <+12>: add    x0, x0, #0xa25 ; "ParseObjCMethod"
Target 0: (lldb) stopped.
(lldb) bt
* thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert
    frame #0: 0x0000000180d08600 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000180d40f50 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x0000000180c4d908 libsystem_c.dylib`abort + 128
    frame #3: 0x0000000180c4cc1c libsystem_c.dylib`__assert_rtn + 284
  * frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) + 
    frame #5: 0x0000000109d30acc liblldb.20.0.0git.dylib`lldb_private::TypeSystemClang::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding, unsigned long) + 1188
    frame #6: 0x0000000109aaaed4 liblldb.20.0.0git.dylib`DynamicLoaderMacOS::NotifyBreakpointHit(void*, lldb_private::StoppointCallbackContext*, unsigned long long, unsigned long long) + 384
```

This patch adds a one-time user-visible warning for when we fail to
initialize the AST to indicate that initialization went wrong for the
given target. Additionally, we add checks for whether one of the
`ASTContext` `QualType`s is invalid before dereferencing any builtin
types.

The warning would look as follows:
```
(lldb) target create "a.out"
Current executable set to 'a.out' (arm64).
(lldb) b main
warning: Failed to initialize builtin ASTContext types for target 'some-unknown-triple'. Printing variables may behave unexpectedly.
Breakpoint 1: where = a.out`main + 8 at stepping.cpp:5:14, address = 0x0000000100003f90
```

rdar://134869779
AZero13 pushed a commit that referenced this pull request Oct 28, 2024
@DavidSpickett
[lldb][test] Make vector operator[] return T& to workaround Arm codeg…
c47df3e 
…en issue

Since llvm#109628 landed, this test
has been failing on 32-bit Arm.

This is due to a codegen problem (whether added or uncovered by the change,
not known) where the trap instruction is placed after the frame pointer
and link register are restored.

llvm#113154

So the code was:
```
std::__1::vector<int>::operator[](unsigned int):
  sub sp, sp, #8
  str r0, [sp, #4]
  str r1, [sp]
  add sp, sp, #8
  .inst 0xe7ffdefe
  bx lr
```
When lldb saw the trap, the PC was inside operator[] but the frame
information actually pointed to g.

This bug only happens for leaf functions so adding a return type
works around it:
```
std::__1::vector<int>::operator[](unsigned int):
  push {r11, lr}
  mov r11, sp
  sub sp, sp, #8
  str r0, [sp, #4]
  str r1, [sp]
  mov sp, r11
  pop {r11, lr}
  .inst 0xe7ffdefe
  bx lr
```
(and operator[] should return T& anyway)

Now the PC location and frame information should match and the
test passes.
AZero13 pushed a commit that referenced this pull request Nov 14, 2024
@chandraghale
Fix for codegen Crash in Clang when using locator omp_all_memory with…
44a6b3a 
… depobj construct (llvm#114221)

A codegen crash is occurring when a depend object was initialized with
omp_all_memory in the depobj directive.
llvm#114214
The root cause of issue looks to be the improper handling of the
dependency list when omp_all_memory was specified.

The change introduces the use of OMPTaskDataTy to manage dependencies.
The buildDependences function is called to construct the dependency
list, and the list is iterated over to emit and store the dependencies.

Reduced Test Case : 
```
#include <omp.h>

int main()

{ omp_depend_t obj; #pragma omp depobj(obj) depend(inout: omp_all_memory) }
```

```
 #1 0x0000000003de6623 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f8e4a6b990f (/lib64/libpthread.so.0+0x1690f)
 #3 0x00007f8e4a117d2a raise (/lib64/libc.so.6+0x4ad2a)
 #4 0x00007f8e4a1193e4 abort (/lib64/libc.so.6+0x4c3e4)
 #5 0x00007f8e4a10fc69 __assert_fail_base (/lib64/libc.so.6+0x42c69)
 #6 0x00007f8e4a10fcf1 __assert_fail (/lib64/libc.so.6+0x42cf1)
 #7 0x0000000004114367 clang::CodeGen::CodeGenFunction::EmitOMPDepobjDirective(clang::OMPDepobjDirective const&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4114367)
 #8 0x00000000040f8fac clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x40f8fac)
 #9 0x00000000040ff4fb clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x40ff4fb)
#10 0x00000000041847b2 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41847b2)
#11 0x0000000004199e4a clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4199e4a)
#12 0x00000000041f7b9d clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41f7b9d)
#13 0x00000000041f16a3 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41f16a3)
#14 0x00000000041fd954 clang::CodeGen::CodeGenModule::EmitDeferred() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41fd954)
#15 0x0000000004200277 clang::CodeGen::CodeGenModule::Release() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4200277)
#16 0x00000000046b6a49 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) ModuleBuilder.cpp:0:0
#17 0x00000000046b4cb6 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x46b4cb6)
#18 0x0000000006204d5c clang::ParseAST(clang::Sema&, bool, bool) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x6204d5c)
#19 0x000000000496b278 clang::FrontendAction::Execute() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x496b278)
#20 0x00000000048dd074 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x48dd074)
#21 0x0000000004a38092 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4a38092)
#22 0x0000000000fd4e9c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0xfd4e9c)
#23 0x0000000000fcca73 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#24 0x0000000000fd140c clang_main(int, char**, llvm::ToolContext const&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0xfd140c)
#25 0x0000000000ee2ef3 main (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0xee2ef3)
#26 0x00007f8e4a10224c __libc_start_main (/lib64/libc.so.6+0x3524c)
#27 0x0000000000fcaae9 _start /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:120:0
clang: error: unable to execute command: Aborted
```

---------

Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>
AZero13 pushed a commit that referenced this pull request Nov 26, 2024
@Tazdevil971
[MIPS] Updated MIPS N calling conventions so that fp16 arguments no l…
8cd348c 
…onger cause a crash (llvm#116569)

This PR fixes a bug introduced by llvm#110199, which causes any half float
argument to crash the compiler on MIPS64.

Currently compiling this bit of code with `llc -mtriple=mips64`: 
```
define void @half_args(half %a) nounwind {
entry:
        ret void
}
```

Crashes with the following log:
```
LLVM ERROR: unable to allocate function argument #0
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: llc -mtriple=mips64
1.	Running pass 'Function Pass Manager' on module '<stdin>'.
2.	Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@half_args'
 #0 0x000055a3a4013df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32d0df8)
 #1 0x000055a3a401199e llvm::sys::RunSignalHandlers() (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32ce99e)
 #2 0x000055a3a40144a8 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f00bde558c0 __restore_rt libc_sigaction.c:0:0
 #4 0x00007f00bdea462c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f00bde55822 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007f00bde3e4af abort ./stdlib/abort.c:81:7
 #7 0x000055a3a3f80e3c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x323de3c)
 #8 0x000055a3a2e20dfa (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x20dddfa)
 #9 0x000055a3a2a34e20 llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const MipsISelLowering.cpp:0:0
#10 0x000055a3a3d896a9 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30466a9)
#11 0x000055a3a3e0b3ec llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c83ec)
#12 0x000055a3a3e09e21 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c6e21)
#13 0x000055a3a2aae1ca llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) MipsISelDAGToDAG.cpp:0:0
#14 0x000055a3a3e07706 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c4706)
#15 0x000055a3a3051ed6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x230eed6)
#16 0x000055a3a35a3ec9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x2860ec9)
#17 0x000055a3a35ac3b2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x28693b2)
#18 0x000055a3a35a499c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x286199c)
#19 0x000055a3a262abbb main (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x18e7bbb)
#20 0x00007f00bde3fc4c __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#21 0x00007f00bde3fd05 call_init ./csu/../csu/libc-start.c:128:20
#22 0x00007f00bde3fd05 __libc_start_main@GLIBC_2.2.5 ./csu/../csu/libc-start.c:347:5
#23 0x000055a3a2624921 _start /builddir/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0
```

This is caused by the fact that after the change, `f16`s are no longer
lowered as `f32`s in calls.

Two possible fixes are available:
- Update calling conventions to properly support passing `f16` as
integers.
- Update `useFPRegsForHalfType()` to return `true` so that `f16` are
still kept in `f32` registers, as before llvm#110199.

This PR implements the first solution to not introduce any more ABI
changes as llvm#110199 already did.

As of what is the correct ABI for halfs, I don't think there is a
correct answer. GCC doesn't support halfs on MIPS, and I couldn't find
any information on old MIPS ABI manuals either.
AZero13 pushed a commit that referenced this pull request Feb 1, 2025
@adrian-prantl
[lldb] Extend frame recognizers to hide frames from backtraces (llvm#…
e2fc5d0 
…104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but the
compiler/runtime itself. This patch introduces a user-extensible
mechanism that allows for these frames to be hidden from backtraces and
automatically skipped over when navigating the stack with `up` and
`down`.

This does not affect the numbering of frames, so `f <N>` will still
provide access to the hidden frames. The `bt` output will also print a
hint that frames have been hidden.

My primary motivation for this feature is to hide thunks in the Swift
programming language, but I'm including an example recognizer for
`std::function::operator()` that I wished for myself many times while
debugging LLDB.

rdar://126629381

Example output. (Yes, my proof-of-concept recognizer could hide even
more frames if we had a method that returned the function name without
the return type or I used something that isn't based off regex, but it's
really only meant as an example).

before:
```
(lldb) thread backtrace --filtered=false
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
    frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
    frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
    frame #3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12
    frame #4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10
    frame #5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12
    frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
    frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
    frame #8: 0x0000000183cdf154 dyld`start + 2476
(lldb)
```

after

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
    frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
    frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
    frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
    frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
    frame #8: 0x0000000183cdf154 dyld`start + 2476
Note: Some frames were hidden by frame recognizers
```

(cherry picked from commit f01f80c)
AZero13 pushed a commit that referenced this pull request Feb 1, 2025
@Michael137
[lldb][TypeSystemClang] Add warning and defensive checks when ASTCont…
b09c5d3 
…ext is not fully initialized (llvm#110481)

As this comment around target initialization implies:
```
  // This can be NULL if we don't know anything about the architecture or if
  // the target for an architecture isn't enabled in the llvm/clang that we
  // built
```

There are cases where we might fail to call `InitBuiltinTypes` when
creating the backing `ASTContext` for a `TypeSystemClang`. If that
happens, the builtins `QualType`s, e.g., `VoidPtrTy`/`IntTy`/etc., are
not initialized and dereferencing them as we do in
`GetBuiltinTypeForEncodingAndBitSize` (and other places) will lead to
nullptr-dereferences. Example backtrace:
```
(lldb) run
Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file Type.h, line 958.
Process 2680 stopped
* thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert
    frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) +
liblldb.20.0.0git.dylib`DWARFASTParserClang::ParseObjCMethod(lldb_private::ObjCLanguage::MethodName const&, lldb_private::plugin::dwarf::DWARFDIE const&, lldb_private::CompilerType, ParsedDWARFTypeAttributes
, bool) (.cold.1):
->  0x10cdf3cdc <+0>:  stp    x29, x30, [sp, #-0x10]!
    0x10cdf3ce0 <+4>:  mov    x29, sp
    0x10cdf3ce4 <+8>:  adrp   x0, 545
    0x10cdf3ce8 <+12>: add    x0, x0, #0xa25 ; "ParseObjCMethod"
Target 0: (lldb) stopped.
(lldb) bt
* thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert
    frame #0: 0x0000000180d08600 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000180d40f50 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x0000000180c4d908 libsystem_c.dylib`abort + 128
    frame #3: 0x0000000180c4cc1c libsystem_c.dylib`__assert_rtn + 284
  * frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) +
    frame #5: 0x0000000109d30acc liblldb.20.0.0git.dylib`lldb_private::TypeSystemClang::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding, unsigned long) + 1188
    frame #6: 0x0000000109aaaed4 liblldb.20.0.0git.dylib`DynamicLoaderMacOS::NotifyBreakpointHit(void*, lldb_private::StoppointCallbackContext*, unsigned long long, unsigned long long) + 384
```

This patch adds a one-time user-visible warning for when we fail to
initialize the AST to indicate that initialization went wrong for the
given target. Additionally, we add checks for whether one of the
`ASTContext` `QualType`s is invalid before dereferencing any builtin
types.

The warning would look as follows:
```
(lldb) target create "a.out"
Current executable set to 'a.out' (arm64).
(lldb) b main
warning: Failed to initialize builtin ASTContext types for target 'some-unknown-triple'. Printing variables may behave unexpectedly.
Breakpoint 1: where = a.out`main + 8 at stepping.cpp:5:14, address = 0x0000000100003f90
```

rdar://134869779
(cherry picked from commit a5f3a2a)
AZero13 pushed a commit that referenced this pull request Feb 1, 2025
@Michael137
[lldb][ObjC] Fix use-after-scope in NSTimeZoneSummaryProvider
16567a1 
This was reported by a test-suite run in a local ASAN/UBSAN build on my M1:
```
=================================================================
==69533==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000106b68e50 at pc 0x00011cacfaa4 bp 0x00016b8c7ff0 sp 0x00016b8c7fe8
READ of size 8 at 0x000106b68e50 thread T0
    #0 0x11cacfaa0 in lldb_private::ValueObject::GetChildAtNamePath(llvm::ArrayRef<llvm::StringRef>) ValueObject.cpp:471
    #1 0x11ce85908 in lldb_private::formatters::NSTimeZoneSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&) Cocoa.cpp:157
    #2 0x11c51bad0 in lldb_private::CXXFunctionSummaryFormat::FormatObject(lldb_private::ValueObject*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) TypeSummary.cpp:129
    #3 0x11cad2eb4 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) ValueObject.cpp:691
    #4 0x11cad2b18 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb::LanguageType) ValueObject.cpp:648
    #5 0x11c528d38 in lldb_private::ValueObjectPrinter::GetValueSummaryError(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_strin
g<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) ValueObjectPrinter.cpp:402
    #6 0x11c526604 in lldb_private::ValueObjectPrinter::PrintValueAndSummaryIfNeeded(bool&, bool&) ValueObjectPrinter.cpp:420
    #7 0x11c524748 in lldb_private::ValueObjectPrinter::PrintValueObject() ValueObjectPrinter.cpp:91
    #8 0x11cae7a10 in lldb_private::ValueObject::Dump(lldb_private::Stream&, lldb_private::DumpValueObjectOptions const&) ValueObject.cpp:2826
    #9 0x11d9ed628 in CommandObjectFrameVariable::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) CommandObjectFrame.cpp:679
    #10 0x11c67f3e4 in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) CommandObject.cpp:826
    #11 0x11c65f9d4 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) CommandInterpreter.cpp:2101
    #12 0x11bdb72a8 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:194
    #13 0x11bdb6a00 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:176
    #14 0x11c1612e8 in _wrap_SBCommandInterpreter_HandleCommand(_object*, _object*) LLDBWrapPython.cpp:16926
```

I'm not sure why this doesn't show up in the public ASAN bot, but
binding a temporary initializer-list to a non-owning `ArrayRef` like
this isn't safe.
AZero13 pushed a commit that referenced this pull request Feb 1, 2025
@Michael137
Merge pull request llvm#9605 from swiftlang/bugfix/lldb-objc-formatte…
b76740b 
…r-asan-to-20240723

[lldb][ObjC] Fix use-after-scope in NSTimeZoneSummaryProvider

This was reported by a test-suite run in a local ASAN/UBSAN build on my M1:
```
=================================================================
==69533==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000106b68e50 at pc 0x00011cacfaa4 bp 0x00016b8c7ff0 sp 0x00016b8c7fe8
READ of size 8 at 0x000106b68e50 thread T0
    #0 0x11cacfaa0 in lldb_private::ValueObject::GetChildAtNamePath(llvm::ArrayRef<llvm::StringRef>) ValueObject.cpp:471
    #1 0x11ce85908 in lldb_private::formatters::NSTimeZoneSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&) Cocoa.cpp:157
    #2 0x11c51bad0 in lldb_private::CXXFunctionSummaryFormat::FormatObject(lldb_private::ValueObject*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) TypeSummary.cpp:129
    #3 0x11cad2eb4 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb_private::TypeSummaryOptions const&) ValueObject.cpp:691
    #4 0x11cad2b18 in lldb_private::ValueObject::GetSummaryAsCString(lldb_private::TypeSummaryImpl*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, lldb::LanguageType) ValueObject.cpp:648
    #5 0x11c528d38 in lldb_private::ValueObjectPrinter::GetValueSummaryError(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::basic_strin
g<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) ValueObjectPrinter.cpp:402
    #6 0x11c526604 in lldb_private::ValueObjectPrinter::PrintValueAndSummaryIfNeeded(bool&, bool&) ValueObjectPrinter.cpp:420
    #7 0x11c524748 in lldb_private::ValueObjectPrinter::PrintValueObject() ValueObjectPrinter.cpp:91
    #8 0x11cae7a10 in lldb_private::ValueObject::Dump(lldb_private::Stream&, lldb_private::DumpValueObjectOptions const&) ValueObject.cpp:2826
    #9 0x11d9ed628 in CommandObjectFrameVariable::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) CommandObjectFrame.cpp:679
    #10 0x11c67f3e4 in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) CommandObject.cpp:826
    #11 0x11c65f9d4 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) CommandInterpreter.cpp:2101
    #12 0x11bdb72a8 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:194
    #13 0x11bdb6a00 in lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) SBCommandInterpreter.cpp:176
    #14 0x11c1612e8 in _wrap_SBCommandInterpreter_HandleCommand(_object*, _object*) LLDBWrapPython.cpp:16926
```

I'm not sure why this doesn't show up in the public ASAN bot, but binding a temporary initializer-list to a non-owning `ArrayRef` like this isn't safe.
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
@AZero13