[PGO] Use fprofile-continuous in compiler-rt tests #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
w2yehia
force-pushed
the
pgo_cont_tests
branch
3 times, most recently
from
6e5badd to
caa6391
Compare
… (NFC) (llvm#126175) I suggested using a lambda in llvm#126171 but @jasonmolenda missed it.
The current legality check for folding with EVL has incomplete verification for VF. This patch fixes the VF check, ensuring that tail folding with EVL is enabled only when a scalable VF is available. This allows loops that prefer tail folding with EVL but cannot use scalable VF vectorization to still be vectorized using a fixed VF, rather than abandoning vectorization entirely.
The config is currently not movable and because there are constructors the default move won't be generated, which prevents it from being moved. Also, it is not copyable because of the unique_ptr. This PR adds move constructor to allow moving it.
This was ultimately working around bugs in subregister handling in peephole-opt. In the common case, it would give up on folding anything into a subregister extract copy.
…lvm#125642) RISCV Zicfilp/Zicfiss extensions uses the `.note.gnu.property` section to store flags indicating the adoption of features based on these extensions. This patch enables the llvm-readobj/llvm-readelf tools to dump these flags with the `--note` flag.
…lues. The getBootstrapMap, getBootstrapMapValue, getBootstrapSymbolsMap, and getBootstrapSymbols methods forward to their respective counterparts in ExecutorProcessControl, similar to the callWrapper functions. These methods will be used to simplify an upcoming patch that accesses the bootstrap values.
…, LLJIT. The system libunwind on older Darwins does not support JIT registration of compact-unwind. Since the CompactUnwindManager utility discards redundant eh-frame FDEs by default we need to remove the compact-unwind section first when targeting older libunwinds in order to preserve eh-frames. While LLJIT was already doing this as of eae6d6d, MachOPlatform was not. This was causing buildbot failures in the ORC runtime (e.g. in https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/3479/). This patch updates both LLJIT and MachOPlatform to check a bootstrap value, "darwin-use-ehframes-only", to determine whether to forcibly preserve eh-frame sections. If this value is present and set to true then compact-unwind sections will be discarded, causing eh-frames to be preserved. If the value is absent or set to false then compact-unwind will be used and redundant FDEs in eh-frames discarded (FDEs that are needed by the compact-unwind section are always preserved). rdar://143895614
The C++ standard prohibits this implicit destructor call, leading to incorrect reports from clang-analyzer. This causes projects that use std::option (including llvm) to fail the cplusplus.NewDelete test incorrectly when run through the analyzer. Fixes llvm#119415
With this patch, we are enabling comparisons for Long double (80) types on X87 stack. It lowers G_FCMP. --------- Co-authored-by: mattarde <[email protected]>
MemProfiler.cpp annotates the IR with the memory profile so that we can later duplicate context. This patch dumps the entire inline call stack for each call site match.
/llvm-project/llvm/lib/Target/X86/GISel/X86InstructionSelector.cpp:1054:9:
error: unused variable 'RhsBank' [-Werror,-Wunused-variable]
auto *RhsBank = RBI.getRegBank(RhsReg, MRI, TRI);
^
1 error generated.
…_slice` (2/N) (llvm#123031) For context, recall that `tensor.insert_slice` is vectorised using the `vector.transfer_read` + `vector.transfer_write` pair. An unmasked example is shown below: ```mlir // BEFORE VECTORIZATION %res = tensor.insert_slice %slice into %dest[0, %c2] [5, 1] [1, 1] : tensor<5x1xi32> into tensor<5x3xi32> // AFTER VECTORIZATION %read = vector.transfer_read %source[%c0, %c0], %pad : tensor<5x1xi32>, vector<8x1xi32> %res = vector.transfer_write %read, %dest[%c0, %c2] : vector<8x1xi32>, tensor<5x3xi32> ``` This PR extends `vectorizeAsInsertSliceOp` to add masking support for the `vector.transfer_write` operation. This complements the changes in llvm#122927, which introduced masking for the `vector.transfer_read`.
…o const sized array are not warned (llvm#125483) Add more tests, where the index of the const array access evaluates to a constant and depends on a template argument. rdar://143759014 Co-authored-by: MalavikaSamak <[email protected]>
…#125918) Following llvm#124308, this patch reorganizes the `vector-to-llvm.mlir` tests by splitting them into two categories: - **Basic conversion tests**: Tests that only require `populateVectorToLLVMConversionPatterns`, focusing on the minimal conversion from Vector to LLVM. These have been moved to `vector-to-llvm-interface.mlir`. - **Full pass tests**: Tests that require the complete `ConvertVectorToLLVMPass`, which includes `populateVectorToLLVMConversionPatterns` along with additional patterns. These remain in `vector-to-llvm.mlir`. This reorganization clarifies test coverage and helps avoid unnecessary duplication. NOTE: This is merely moving tests around between two files and adds some comments.
Found using https://github.com/codespell-project/codespell ``` codespell RISCV --write-changes \ --ignore-words-list=FPR,fpr,VAs,ORE,WorstCase,hart,sie,MIs,FLE,fle,CarryIn,vor,OLT,VILL,vill,bu,pass-thru ```
This is an external tool, so I don't think there is an expectation that it has to be in the LLVM tools bindir. It may also be in the default system bindir (which is not necessarily the same).
…f` (llvm#126075) * Remove duplicate `TypeOrContainer`. There is an identical class with the same name: `TypeOrValueSemanticsContainer`. * Remove `TypeOrContainerOfAnyRank` and use `TypeOrValueSemanticsContainer` instead. `TypeOrContainerOfAnyRank` is inconsistent with the other classes because it explicitly checks for `VectorType` and `TensorType` instead of utilizing the value semantics type trait. * Remove `SignlessIntegerOrIndexLikeOfAnyRank` etc. and use `SignlessIntegerOrIndexLike` instead. `SignlessIntegerOrIndexLike` etc. already allow 0-d vectors, so there is no difference with `SignlessIntegerOrIndexLikeOfAnyRank`.
…ops (llvm#124268) Does a select on the input rather than the output. This way the mask has the same number of lanes as the other operand in the select instruction.
This adds the `llvm.modf` intrinsic, legalization, and lowering (mostly
reusing the lowering for sincos and frexp).
The `llvm.modf` intrinsic takes a floating-point value and returns both
the integral and fractional parts (as a struct).
```
declare { float, float } @llvm.modf.f32(float %Val)
declare { double, double } @llvm.modf.f64(double %Val)
declare { x86_fp80, x86_fp80 } @llvm.modf.f80(x86_fp80 %Val)
declare { fp128, fp128 } @llvm.modf.f128(fp128 %Val)
declare { ppc_fp128, ppc_fp128 } @llvm.modf.ppcf128(ppc_fp128 %Val)
declare { <4 x float>, <4 x float> } @llvm.modf.v4f32(<4 x float> %Val)
```
This corresponds to the libm `modf` function but returns multiple values
in a struct (rather than take output pointers), which makes it easier to
vectorize.
…lvm#126053) Setting a breakpoint on `<symbol> + <offset>` used to work until `2c76e88e9eb284d17cf409851fb01f1d583bb22a`, where this regex was reworked. Now we only accept `<symbol>+ <offset>` or `<symbol>+<offset>`. This patch fixes the regression by adding yet another `[[:space:]]*` component to the regex. One could probably simplify the regex (or even replace the regex by just calling the relevent `consumeXXX` APIs on `llvm::StringRef`). Though I left that for the future. rdar://130780342
…llvm#126045) This is the 2nd part to llvm#124752. Here we make sure to set the `DICompositeType` `EnumKind` if the enum was declared with `__attribute__((enum_extensibility(...)))`. In DWARF this will be rendered as `DW_AT_APPLE_enum_kind` and will be used by LLDB when creating `clang::EnumDecl`s from debug-info. Depends on llvm#126044
This was meant to assert that we have the same number of names as we do formal parameter types (since callers of this API rely on this being true).
…5716) The legacy and vplan cost models did not agree because VPWidenCallRecipe::computeCost only calculates the cost of the call instruction, whereas LoopVectorizationCostModel::setVectorizedCallDecision in some cases adds on the cost of a synthesised mask argument. However, this mask is always 'splat(i1 true)' which should be hoisted out of the loop during codegen. In order to synchronise the two cost models I have two options: 1) Also add the cost of the splat to the vplan model, or 2) Remove the cost of the splat from the legacy model. I chose 2) because I feel this more closely represents what the final code will look like. There is an argument that we should take account of such broadcast costs in the preheader when deciding if it's profitable to vectorise a loop, however there isn't currently a mechanism to do this. We currently only take account of the runtime checks when assessing profitability and what the minimum trip count should be. However, I don't believe this work needs doing as part of this PR.
Fixes 0cbc498. llvm-project/lldb/unittests/ValueObject/DynamicValueObjectLocalBuffer.cpp(221): error C2065: 'u_int8_t': undeclared identifier
Fixes issue caused by 1930524 Unused variable UsesMask in LoopVectorize.cpp
…lvm#125861) llvm-readobj print out symbol value name for xcoff symbol table. reference doc: https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__yaa3i18fjbau
…25840) isBasicBlockEntryGuardedByCond inadvertedenly drops samesign information when calling ICmpInst::getNonStrictPredicate. Fix this.
…ions (llvm#126483) This patch adds the remaining support for fixed-point arithmetic instructions (we previously had support for averaging adds and subtracts). For saturating adds/subs/multiplies/clips, we can't change `vl` if `vxsat` is used, since changing `vl` may change its value. So this patch checks to see if it's dead before considering it a candidate.
…r like gcc (llvm#126524) We now process all 6 options left-to-right and pick whatever is active at the end. Fixes llvm#124868.
* Drop ".Z" in milestone name since we've been doing X.Y releases instead of X.Y.Z releases since LLVM 18 * Add "LLVM" prefix since that's what release milestones are named * Use a numbered list to make it clearer that there are two steps needed, and add some more details to the first step
…llvm#126167) OpenACC specification describes the following type categories: scalar, array, composite, and aggregate (which includes arrays, composites, and others such as Fortran pointer/allocatable). Decision for how to do implicit mapping is dependent on a variable's category. Since acc dialect's only means of distinguishing between types is through the interfaces attached, add API to be able to get the type category. In addition to defining the new API, attempt to provide a base implementation for memref which matches what OpenACC spec describes.
* Adds variants of dotp (dotp_i8_to_i64_has_neon_dotprod, dotp_i16_to_i64_has_neon_dotprod) that show how the loop vectoriser has generated fixed-width partial reductions without any matching NEON udot instruction. * Adds loops that could also benefit from partial reductions once the work is done to recognise patterns such as %zext = zext i8 %load to i32 %acc.next = add i32 %acc, %zext See zext_add_reduc_i8_i32, etc. I intend to follow up with a patch to add support for vectorising such patterns.
I got a report that downstream this test failed and the cause was that it took longer than the 1 second we expected to run one of the test cases. This test doesn't need to be that specific, so I am updating all the time regexes to be the same one that allows 0-9 any number of digits, requires a decimal point, then 0-9 any number of digits for the final part.
…lvm#126087) I tried to fix it in llvm#124051 but failed to do so. This PR adds the test and marks it as xfail.
…ded (llvm#126137) - Detect whether logical operand mapping/named operand mappings have been enabled in a previous pass over instructions and execute the relevant emission code only if those mappings are enabled. - For these mappings, skip the fixed set of predefined instructions as they won't have these mappings enabled. - Emit operand type mappings only for X86 target, as they are only used by X86 and look for X86 specific `X86MemOperand`. - Cleanup `emitOperandTypeMappings` code: remove code to handle empty instruction list and use range for loops.
…end support (llvm#125920) As Intel is working to add support for SPIR-V OpenMP device offloading in upstream clang/liboffload, we need to modify the OpenMP frontend to allow SPIR-V as well as generate valid IR for SPIR-V. For example, we need the frontend to generate code to define and interact with device globals used in the DeviceRTL. This is the beginning of what I expect will be (many) other changes, but let's get started with something simple. --------- Signed-off-by: Sarnie, Nick <[email protected]>
…nd 1 (llvm#126170) llvm#123331 added support for the unrolling directive. In the presence of an explicit unrolling factor, that unrolling factor would be unconditionally passed into the metadata even when it was 1 or 0. These special cases should instead disable unrolling. Adding an explicit unrolling factor of 0 triggered this assertion which is fixed by this patch: ``` unsigned int unrollCountPragmaValue(const llvm::Loop*): Assertion `Count >= 1 && "Unroll count must be positive."' failed. ``` Updated tests and documentation.
… it to extractOp and insertOp. (llvm#124399) add extractInsertFoldConstantOp fold function and apply it to extractOp and insertOp.
w2yehia
force-pushed
the
pgo_cont_tests
branch
from
caa6391 to
4e8be20
Compare
w2yehia
pushed a commit
that referenced
this pull request
Feb 19, 2025
We can't guaranty that underlying string is 0-terminated and [String.size()] is even in the same allocation. https://lab.llvm.org/buildbot/#/builders/94/builds/4152/steps/17/logs/stdio ``` ==c-index-test==1846256==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::cxstring::createRef(llvm::StringRef) llvm-project/clang/tools/libclang/CXString.cpp:96:36 #1 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:521:39 llvm#2 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7 llvm#3 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7 llvm#4 in DumpCXComment llvm-project/clang/tools/c-index-test/c-index-test.c:685:3 llvm#5 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:768:7 Memory was marked as uninitialized #0 in __msan_allocated_memory llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1023:5 #1 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:172:7 llvm#2 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:216:12 llvm#3 in Allocate llvm-project/llvm/include/llvm/Support/AllocatorBase.h:53:43 llvm#4 in Allocate<char> llvm-project/llvm/include/llvm/Support/AllocatorBase.h:76:29 llvm#5 in convertCodePointToUTF8 llvm-project/clang/lib/AST/CommentLexer.cpp:42:30 llvm#6 in clang::comments::Lexer::resolveHTMLDecimalCharacterReference(llvm::StringRef) const llvm-project/clang/lib/AST/CommentLexer.cpp:76:10 llvm#7 in clang::comments::Lexer::lexHTMLCharacterReference(clang::comments::Token&) llvm-project/clang/lib/AST/CommentLexer.cpp:615:16 llvm#8 in consumeToken llvm-project/clang/include/clang/AST/CommentParser.h:62:9 llvm#9 in clang::comments::Parser::parseParagraphOrBlockCommand() llvm-project/clang/lib/AST/CommentParser.cpp llvm#10 in clang::comments::Parser::parseFullComment() llvm-project/clang/lib/AST/CommentParser.cpp:925:22 llvm#11 in clang::RawComment::parse(clang::ASTContext const&, clang::Preprocessor const*, clang::Decl const*) const llvm-project/clang/lib/AST/RawCommentList.cpp:221:12 llvm#12 in clang::ASTContext::getCommentForDecl(clang::Decl const*, clang::Preprocessor const*) const llvm-project/clang/lib/AST/ASTContext.cpp:714:35 llvm#13 in clang_Cursor_getParsedComment llvm-project/clang/tools/libclang/CXComment.cpp:36:35 llvm#14 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:756:25 ```
w2yehia
pushed a commit
that referenced
this pull request
Feb 19, 2025
Reverts llvm#125020 https://lab.llvm.org/buildbot/#/builders/24/builds/5252/steps/12/logs/stdio ``` ==c-index-test==2512295==ERROR: AddressSanitizer: heap-use-after-free on address 0xe19338c27992 at pc 0xc66be4784830 bp 0xe0e33660df00 sp 0xe0e33660d6e8 READ of size 23 at 0xe19338c27992 thread T1 #0 0xc66be478482c in printf_common(void*, char const*, std::__va_list) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:563:9 #1 0xc66be478643c in vprintf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1699:1 llvm#2 0xc66be478643c in printf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1757:1 llvm#3 0xc66be4839384 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1359:5 llvm#4 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 llvm#5 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp 0xe19338c27992 is located 82 bytes inside of 105-byte region [0xe19338c27940,0xe19338c279a9) freed by thread T1 here: #0 0xc66be480040c in free /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:51:3 #1 0xc66be4839728 in GetCursorSource c-index-test.c llvm#2 0xc66be4839368 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1360:12 llvm#3 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11 llvm#4 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp previously allocated by thread T1 here: #0 0xc66be4800680 in malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0xe4e3456379b0 in safe_malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/Support/MemAlloc.h:26:18 llvm#2 0xe4e3456379b0 in createDup /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:95:40 llvm#3 0xe4e3456379b0 in clang::cxstring::createRef(llvm::StringRef) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:90:10 ```
w2yehia
pushed a commit
that referenced
this pull request
Feb 19, 2025
…127087) Fixes the following crash in clang-repl ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( clang-repl: /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1757: void clang::DeclContext::addHiddenDecl(clang::Decl*): Assertion `D->getLexicalDeclContext() == this && "Decl inserted into wrong lexical context"' failed. #0 0x000059b28459e6da llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:804:22 #1 0x000059b28459eaed PrintStackTraceSignalHandler(void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:880:1 llvm#2 0x000059b28459bf7f llvm::sys::RunSignalHandlers() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Signals.cpp:105:20 llvm#3 0x000059b28459df8e SignalHandler(int, siginfo_t*, void*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/llvm/lib/Support/Unix/Signals.inc:418:13 llvm#4 0x000077cdf444ea50 (/usr/lib/libc.so.6+0x42a50) llvm#5 0x000077cdf44aee3b pthread_kill (/usr/lib/libc.so.6+0xa2e3b) llvm#6 0x000077cdf444e928 raise (/usr/lib/libc.so.6+0x42928) llvm#7 0x000077cdf443156c abort (/usr/lib/libc.so.6+0x2556c) llvm#8 0x000077cdf44314d2 __assert_perror_fail (/usr/lib/libc.so.6+0x254d2) llvm#9 0x000077cdf4444c56 (/usr/lib/libc.so.6+0x38c56) llvm#10 0x000059b28495bfc4 clang::DeclContext::addHiddenDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1759:3 llvm#11 0x000059b28495c0f5 clang::DeclContext::addDecl(clang::Decl*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/AST/DeclBase.cpp:1785:37 llvm#12 0x000059b28773cc2a clang::Sema::ActOnStartTopLevelStmtDecl(clang::Scope*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Sema/SemaDecl.cpp:20302:18 llvm#13 0x000059b286f1efdf clang::Parser::ParseTopLevelStmtDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/ParseDecl.cpp:6024:62 llvm#14 0x000059b286ef18ee clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:1065:35 llvm#15 0x000059b286ef0702 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Parse/Parser.cpp:758:36 llvm#16 0x000059b28562dff2 clang::IncrementalParser::ParseOrWrapTopLevelDecl() /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:66:36 llvm#17 0x000059b28562e5b7 clang::IncrementalParser::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/IncrementalParser.cpp:132:8 llvm#18 0x000059b28561832b clang::Interpreter::Parse(llvm::StringRef) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:570:8 llvm#19 0x000059b285618cbd clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/lib/Interpreter/Interpreter.cpp:649:8 llvm#20 0x000059b2836f9343 main /home/vipul-cariappa/Documents/Workspace/cpp-py/llvms/llvm-project-a/clang/tools/clang-repl/ClangRepl.cpp:255:59 llvm#21 0x000077cdf443388e (/usr/lib/libc.so.6+0x2788e) llvm#22 0x000077cdf443394a __libc_start_main (/usr/lib/libc.so.6+0x2794a) llvm#23 0x000059b2836f7965 _start (./bin/clang-repl+0x73b8965) fish: Job 1, './bin/clang-repl' terminated by signal SIGABRT (Abort) ``` With this change: ```c++ clang-repl> try { throw 1; } catch { 0; } In file included from <<< inputs >>>:1: input_line_1:1:23: error: expected '(' 1 | try { throw 1; } catch { 0; } | ^ | ( error: Parsing failed. clang-repl> 1; clang-repl> %quit ```
w2yehia
pushed a commit
that referenced
this pull request
Feb 19, 2025
For function declarations (i.e. func op has no entry block), the FunctionOpInterface method `insertArgument` and `eraseArgument` will cause segfault. This PR guards against manipulation of empty entry block by checking whether func op is external. An example can be seen in google/heir#1324 The segfault trace ``` #1 0x0000560f1289d9db PrintStackTraceSignalHandler(void*) /proc/self/cwd/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:874:1 llvm#2 0x0000560f1289b116 llvm::sys::RunSignalHandlers() /proc/self/cwd/external/llvm-project/llvm/lib/Support/Signals.cpp:105:5 llvm#3 0x0000560f1289e145 SignalHandler(int) /proc/self/cwd/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:415:1 llvm#4 0x00007f829a3d9520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) llvm#5 0x0000560f1257f8bc void __gnu_cxx::new_allocator<mlir::BlockArgument>::construct<mlir::BlockArgument, mlir::BlockArgument>(mlir::BlockArgument*, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:162:23 llvm#6 0x0000560f1257f84d void std::allocator_traits<std::allocator<mlir::BlockArgument> >::construct<mlir::BlockArgument, mlir::BlockArgument>(std::allocator<mlir::BlockArgument>&, mlir::BlockArgument*, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:520:2 llvm#7 0x0000560f12580498 void std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> >::_M_insert_aux<mlir::BlockArgument>(__gnu_cxx::__normal_iterator<mlir::BlockArgument*, std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> > >, mlir::BlockArgument&&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:405:7 llvm#8 0x0000560f1257cf7e std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> >::insert(__gnu_cxx::__normal_iterator<mlir::BlockArgument const*, std::vector<mlir::BlockArgument, std::allocator<mlir::BlockArgument> > >, mlir::BlockArgument const&) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:154:6 llvm#9 0x0000560f1257b349 mlir::Block::insertArgument(unsigned int, mlir::Type, mlir::Location) /proc/self/cwd/external/llvm-project/mlir/lib/IR/Block.cpp:178:13 llvm#10 0x0000560f123d2a1c mlir::function_interface_impl::insertFunctionArguments(mlir::FunctionOpInterface, llvm::ArrayRef<unsigned int>, mlir::TypeRange, llvm::ArrayRef<mlir::DictionaryAttr>, llvm::ArrayRef<mlir::Location>, unsigned int, mlir::Type) /proc/self/cwd/external/llvm-project/mlir/lib/Interfaces/FunctionInterfaces.cpp:232:11 llvm#11 0x0000560f0be6b727 mlir::detail::FunctionOpInterfaceTrait<mlir::func::FuncOp>::insertArguments(llvm::ArrayRef<unsigned int>, mlir::TypeRange, llvm::ArrayRef<mlir::DictionaryAttr>, llvm::ArrayRef<mlir::Location>) /proc/self/cwd/bazel-out/k8-dbg/bin/external/llvm-project/mlir/include/mlir/Interfaces/FunctionInterfaces.h.inc:809:7 llvm#12 0x0000560f0be6b536 mlir::detail::FunctionOpInterfaceTrait<mlir::func::FuncOp>::insertArgument(unsigned int, mlir::Type, mlir::DictionaryAttr, mlir::Location) /proc/self/cwd/bazel-out/k8-dbg/bin/external/llvm-project/mlir/include/mlir/Interfaces/FunctionInterfaces.h.inc:796:7 ```
w2yehia
pushed a commit
that referenced
this pull request
Mar 31, 2025
… pointers (llvm#132261) Currently, the helpers to get fir::ExtendedValue out of hlfir::Entity use hlfir.declare second result (`#1`) in most cases. This is because this result is the same as the input and matches what FIR was getting before lowering to HLFIR. But this creates odd situations when both hlfir.declare are raw pointers and either result ends-up being used in the IR depending on whether the code was generated by a helper using fir::ExtendedValue, or via "pure HLFIR" helpers using the first result. This will typically prevent simple CSE and easy identification that two operation (e.g load/store) are touching the exact same memory location without using alias analysis or "manual detection" (looking for common hlfir.declare defining op). Hence, when hlfir.declare results are both raw pointers, use `#0` when producing `fir::ExtendedValue`. When `#0` is a fir.box, keep using `#1` because these are not the same. The only code change is in HLFIRTools.cpp and is pretty small, but there is a big test fallout of `#1` to `#0`.
w2yehia
pushed a commit
that referenced
this pull request
Mar 31, 2025
…too. (llvm#132267) Observed in Wine when trying to intercept `ExitThread`, which forwards to `ntdll.RtlExitUserThread`. `gdb` interprets it as `xchg %ax,%ax`. `llvm-mc` outputs simply `nop`. ``` ==Asan-i386-calls-Dynamic-Test.exe==964==interception_win: unhandled instruction at 0x7be27cf0: 66 90 55 89 e5 56 50 8b ``` ``` Wine-gdb> bt #0 0x789a1766 in __interception::GetInstructionSize (address=<optimized out>, rel_offset=<optimized out>) at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/interception/interception_win.cpp:983 #1 0x789ab480 in __sanitizer::SharedPrintfCode(bool, char const*, char*) () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_printf.cpp:311 llvm#2 0x789a18e7 in __interception::OverrideFunctionWithHotPatch (old_func=2078440688, new_func=2023702608, orig_old_func=warning: (Internal error: pc 0x792f1a2c in read in CU, but not in symtab.)warning: (Error: pc 0x792f1a2c in address map, but not in symtab.)0x792f1a2c) at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/interception/interception_win.cpp:1118 llvm#3 0x789a1f34 in __interception::OverrideFunction (old_func=2078440688, new_func=2023702608, orig_old_func=warning: (Internal error: pc 0x792f1a2c in read in CU, but not in symtab.)warning: (Error: pc 0x792f1a2c in address map, but not in symtab.)0x792f1a2c) at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/interception/interception_win.cpp:1224 llvm#4 0x789a24ce in __interception::OverrideFunction (func_name=0x78a0bc43 <vtable for __asan::AsanThreadContext+1163> "ExitThread", new_func=2023702608, orig_old_func=warning: (Internal error: pc 0x792f1a2c in read in CU, but not in symtab.)warning: (Error: pc 0x792f1a2c in address map, but not in symtab.)0x792f1a2c) at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/interception/interception_win.cpp:1369 llvm#5 0x789f40ef in __asan::InitializePlatformInterceptors () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_win.cpp:190 llvm#6 0x789e0c3c in __asan::InitializeAsanInterceptors () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:802 llvm#7 0x789ee6b5 in __asan::AsanInitInternal () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:442 llvm#8 0x789eefb0 in __asan::AsanInitFromRtl () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:522 llvm#9 __asan::AsanInitializer::AsanInitializer (this=<optimized out>) at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:542 llvm#10 __cxx_global_var_init () at C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:546 ... Wine-gdb> disassemble /r 2078440688,2078440688+20 Dump of assembler code from 0x7be27cf0 to 0x7be27d04: 0x7be27cf0 <_RtlExitUserThread@4+0>: 66 90 xchg %ax,%ax ... ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.