-
Notifications
You must be signed in to change notification settings - Fork 146
Fix CIR parsing problem with struct/classes #9
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.
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
Labels
Comments
lanza
pushed a commit
that referenced
this issue
Sep 22, 2022
Commit de3445e (https://reviews.llvm.org/D132096) made changes to isVectorPromotionViable basically doing // Create Vector with size of V, and each element of type Ty ... uint64_t ElementSize = DL.getTypeStoreSizeInBits(Ty).getFixedSize(); uint64_t VectorSize = DL.getTypeSizeInBits(V).getFixedSize(); ... VectorType *VTy = VectorType::get(Ty, VectorSize / ElementSize, false); Not quite sure why it uses the TypeStoreSize for the ElementSize, but the new vector would only match in size with the old vector in situations when the TypeStoreSize equals the TypeSize for Ty. Therefore this patch adds a typeSizeEqualsStoreSize check as yet another condition for allowing the the new type as a promotion candidate. Without this fix the new @test15 test would fail with an assert like this: opt: ../lib/Transforms/Scalar/SROA.cpp:1966: auto isVectorPromotionViable(llvm::sroa::Partition &, const llvm::DataLayout &) ::(anonymous class)::operator()(llvm::VectorType *, llvm::VectorType *) const: Assertion `DL.getTypeSizeInBits(RHSTy).getFixedSize() == DL.getTypeSizeInBits(LHSTy).getFixedSize() && "Cannot have vector types of different sizes!"' failed. ... #8 isVectorPromotionViable(...)::$_10::operator()... #9 llvm::SROAPass::rewritePartition(...) #10 llvm::SROAPass::splitAlloca(...) #11 llvm::SROAPass::runOnAlloca(...) #12 llvm::SROAPass::runImpl(...) #13 llvm::SROAPass::run(...) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D134032
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
Parsing wasn't considering the separating the types inside the brackets, that is used by printing. Related to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
Parsing wasn't considering the separating the types inside the brackets, that is used by printing. Related to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Related to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Related to llvm#9.
cmarcelo
added a commit
to cmarcelo/clangir
that referenced
this issue
Oct 18, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
bcardosolopes
pushed a commit
that referenced
this issue
Oct 20, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
bcardosolopes
pushed a commit
that referenced
this issue
Oct 20, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
I think we can close this one. |
Perfect, thanks for working on it! |
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For the following program, $ cat t.c struct t { int (__attribute__((btf_type_tag("rcu"))) *f)(); int a; }; int foo(struct t *arg) { return arg->a; } Compiling with 'clang -g -O2 -S t.c' will cause a failure like below: clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc): Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: ...... #5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5) #6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79) #7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456) #8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0 #9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0 ...... The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example, the TypeLoc is BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar |-ParenType 0x8861480 'int ()' sugar | `-FunctionNoProtoType 0x8861450 'int ()' cdecl | `-BuiltinType 0x87fd500 'int' while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and this will cause later assertion. To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in GetTypeSourceInfoForDeclarator(). Differential Revision: https://reviews.llvm.org/D136807
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Dec 17, 2022
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Dec 20, 2022
…D112621 It seems like `LHS` and `RHS` could be empty range sets. This caused an assertion failure inside RangeConstraintManager. I'm hoisting out the check from the function into the call-site. This way we could assert that we only want to deal with non-empty range sets. The relevant part of the trace: ``` #6 0x00007fe6ff5f81a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x00007fe6ff5f8252 (/lib64/libc.so.6+0x2f252) #8 0x00000000049caed2 (anonymous namespace)::SymbolicRangeInferrer::VisitBinaryOperator(clang::ento::RangeSet, clang::BinaryOperatorKind, clang::ento::RangeSet, clang::QualType) RangeConstraintManager.cpp:0:0 #9 0x00000000049c9867 (anonymous namespace)::SymbolicRangeInferrer::infer(clang::ento::SymExpr const*) RangeConstraintManager.cpp:0:0 #10 0x00000000049bebf5 (anonymous namespace)::RangeConstraintManager::assumeSymNE(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::SymExpr const*, llvm::APSInt const&, llvm::APSInt const&) RangeConstraintManager.cpp:0:0 #11 0x00000000049d368c clang::ento::RangedConstraintManager::assumeSymUnsupported(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::SymExpr const*, bool) (../../main-github/llvm/build-all/bin/clang+0x49d368c) #12 0x00000000049f0b09 clang::ento::SimpleConstraintManager::assumeAux(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::NonLoc, bool) (../../main-github/llvm/build-all/bin/clang+0x49f0b09) #13 0x00000000049f096a clang::ento::SimpleConstraintManager::assume(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::NonLoc, bool) (../../main-github/llvm/build-all/bin/clang+0x49f096a) #14 0x00000000049f086d clang::ento::SimpleConstraintManager::assumeInternal(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::DefinedSVal, bool) (../../main-github/llvm/build-all/bin/clang+0x49f086d) #15 0x000000000492d3e3 clang::ento::ConstraintManager::assumeDual(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::DefinedSVal) (../../main-github/llvm/build-all/bin/clang+0x492d3e3) #16 0x0000000004955b6d clang::ento::ExprEngine::evalEagerlyAssumeBinOpBifurcation(clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet&, clang::Expr const*) (../../main-github/llvm/build-all/bin/clang+0x4955b6d) #17 0x00000000049514b6 clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (../../main-github/llvm/build-all/bin/clang+0x49514b6) #18 0x000000000494c73e clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*, clang::ento::ExplodedNode*) (../../main-github/llvm/build-all/bin/clang+0x494c73e) #19 0x000000000494c459 clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) (../../main-github/llvm/build-all/bin/clang+0x494c459) #20 0x000000000492f3d0 clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, clang::ento::ExplodedNode*) (../../main-github/llvm/build-all/bin/clang+0x492f3d0) #21 0x000000000492e1f6 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) (../../main-github/llvm/build-all/bin/clang+0x492e1f6) ``` Differential Revision: https://reviews.llvm.org/D112621
lanza
pushed a commit
that referenced
this issue
Dec 20, 2023
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Jan 29, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Jan 29, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Mar 23, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Mar 23, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
eZWALT
pushed a commit
to eZWALT/clangir
that referenced
this issue
Mar 24, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
eZWALT
pushed a commit
to eZWALT/clangir
that referenced
this issue
Mar 24, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
eZWALT
pushed a commit
to eZWALT/clangir
that referenced
this issue
Apr 29, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
eZWALT
pushed a commit
to eZWALT/clangir
that referenced
this issue
Apr 29, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Apr 29, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this issue
Jul 17, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm/clangir#9.
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this issue
Jul 17, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm/clangir#9.
Hugobros3
pushed a commit
to shady-gang/clangir
that referenced
this issue
Oct 2, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
Hugobros3
pushed a commit
to shady-gang/clangir
that referenced
this issue
Oct 2, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
keryell
pushed a commit
to keryell/clangir
that referenced
this issue
Oct 19, 2024
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
keryell
pushed a commit
to keryell/clangir
that referenced
this issue
Oct 19, 2024
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
seven-mile
pushed a commit
to seven-mile/clangir
that referenced
this issue
Nov 13, 2024
… depobj construct (#114221) A codegen crash is occurring when a depend object was initialized with omp_all_memory in the depobj directive. llvm/llvm-project#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) } ``` ``` llvm#1 0x0000000003de6623 SignalHandler(int) Signals.cpp:0:0 llvm#2 0x00007f8e4a6b990f (/lib64/libpthread.so.0+0x1690f) llvm#3 0x00007f8e4a117d2a raise (/lib64/libc.so.6+0x4ad2a) llvm#4 0x00007f8e4a1193e4 abort (/lib64/libc.so.6+0x4c3e4) llvm#5 0x00007f8e4a10fc69 __assert_fail_base (/lib64/libc.so.6+0x42c69) llvm#6 0x00007f8e4a10fcf1 __assert_fail (/lib64/libc.so.6+0x42cf1) llvm#7 0x0000000004114367 clang::CodeGen::CodeGenFunction::EmitOMPDepobjDirective(clang::OMPDepobjDirective const&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4114367) llvm#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) llvm#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) llvm#10 0x00000000041847b2 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41847b2) llvm#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) llvm#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) llvm#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) llvm#14 0x00000000041fd954 clang::CodeGen::CodeGenModule::EmitDeferred() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x41fd954) llvm#15 0x0000000004200277 clang::CodeGen::CodeGenModule::Release() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4200277) llvm#16 0x00000000046b6a49 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) ModuleBuilder.cpp:0:0 llvm#17 0x00000000046b4cb6 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x46b4cb6) llvm#18 0x0000000006204d5c clang::ParseAST(clang::Sema&, bool, bool) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x6204d5c) llvm#19 0x000000000496b278 clang::FrontendAction::Execute() (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x496b278) llvm#20 0x00000000048dd074 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x48dd074) llvm#21 0x0000000004a38092 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0x4a38092) llvm#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) llvm#23 0x0000000000fcca73 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0 llvm#24 0x0000000000fd140c clang_main(int, char**, llvm::ToolContext const&) (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0xfd140c) llvm#25 0x0000000000ee2ef3 main (/opt/cray/pe/cce/18.0.1/cce-clang/x86_64/bin/clang-18+0xee2ef3) llvm#26 0x00007f8e4a10224c __libc_start_main (/lib64/libc.so.6+0x3524c) llvm#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 <[email protected]>
smeenai
pushed a commit
that referenced
this issue
Nov 22, 2024
…onger cause a crash (#116569) This PR fixes a bug introduced by #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 #110199. This PR implements the first solution to not introduce any more ABI changes as #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.
lanza
pushed a commit
that referenced
this issue
Jan 27, 2025
…" (#123877) Reverts llvm/llvm-project#122811 due to buildbot breakage e.g., https://lab.llvm.org/buildbot/#/builders/52/builds/5421/steps/11/logs/stdio ASan output from local re-run: ``` ==2780289==ERROR: AddressSanitizer: use-after-poison on address 0x7e0b87e28d28 at pc 0x55a979a99e7e bp 0x7ffe4b18f0b0 sp 0x7ffe4b18f0a8 READ of size 1 at 0x7e0b87e28d28 thread T0 #0 0x55a979a99e7d in getStorageClass /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:344 #1 0x55a979a99e7d in isSectionDefinition /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/Object/COFF.h:429:9 #2 0x55a979a99e7d in getSymbols /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:54:42 #3 0x55a979a99e7d in lld::coff::writeLLDMapFile(lld::coff::COFFLinkerContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/LLDMapFile.cpp:103:40 #4 0x55a979a16879 in (anonymous namespace)::Writer::run() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:810:3 #5 0x55a979a00aac in lld::coff::writeResult(lld::coff::COFFLinkerContext&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Writer.cpp:354:15 #6 0x55a97985f7ed in lld::coff::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:2826:3 #7 0x55a97984cdd3 in lld::coff::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/COFF/Driver.cpp:97:15 #8 0x55a9797f9793 in lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:163:12 #9 0x55a9797fa3b6 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:188:15 #10 0x55a9797fa3b6 in void llvm::function_ref<void ()>::callback_fn<lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>)::$_0>(long) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 #11 0x55a97966cb93 in operator() /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 #12 0x55a97966cb93 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 #13 0x55a9797f9dc3 in lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/Common/DriverDispatcher.cpp:187:14 #14 0x55a979627512 in lld_main(int, char**, llvm::ToolContext const&) /usr/local/google/home/thurston/buildbot_repro/llvm-project/lld/tools/lld/lld.cpp:103:14 #15 0x55a979628731 in main /usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/tools/lld/tools/lld/lld-driver.cpp:17:10 #16 0x7ffb8b202c89 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #17 0x7ffb8b202d44 in __libc_start_main csu/../csu/libc-start.c:360:3 #18 0x55a97953ef60 in _start (/usr/local/google/home/thurston/buildbot_repro/llvm_build_asan/bin/lld+0x8fd1f60) ```
xlauko
pushed a commit
to xlauko/clangir
that referenced
this issue
Feb 11, 2025
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to llvm#9.
xlauko
pushed a commit
to xlauko/clangir
that referenced
this issue
Feb 11, 2025
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to llvm#9.
lanza
pushed a commit
that referenced
this issue
Mar 18, 2025
The parsing function wasn't considering the commas separating the types inside the angle brackets, that are used by printing. Added a test to round trip a !cir.struct type to cover this code path. Related to #9.
lanza
pushed a commit
that referenced
this issue
Mar 18, 2025
For those types, the mangled name started with a number which is not a valid start character for alias types in MLIR. Prefix these aliases with "ty_". Relates to #9.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For something simple as:
We can emit CIR but not read it back:
We probably need some CIR specific prefix here or something.
The text was updated successfully, but these errors were encountered: