[go: nahoru, domu]

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.

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

Suggest building for the host arch #11

Merged
merged 1 commit into from
Oct 21, 2022

Conversation

AlexDenisov
Copy link
Member

No description provided.

@lanza
Copy link
Member
lanza commented Sep 24, 2022

This is good in principle, but we haven't done the diligence to build all the target specific codegen classes you'd need for this to work. x86_64-unknown-linux-gnu was what we started out with.

@AlexDenisov
Copy link
Member Author

Yeah, the limitations are understood. I'm running Apple Silicon and thought it would be a better default for non-x86 users.

@bcardosolopes
Copy link
Member

@AlexDenisov thanks for fixing the docs, definitely makes sense. Probably better if we change to "X86;AArch64" so the tests can pass - did you end up running the tests?

@AlexDenisov
Copy link
Member Author

Just gave it a try with X86;AArch64: CIR specific ones are passing (ninja check-clang-cir check-clang-cir-codegen),
but something is broken with check-all. I didn't dig deeper, but it seems CIR related:

error: 'error' diagnostics seen but not expected:
  (frontend): generated arguments do not match in round-trip
error: 'note' diagnostics seen but not expected:
  (frontend): generated arguments #1 in round-trip: "-cc1" "-verify" "-o" "-" "-fsyntax-only" "-x" "cir" "/opt/LLVM/clangir/clang/test/SemaHLSL/prohibit_pointer.hlsl" "-triple" "dxil-pc-shadermodel6.0-library" "-nostdsysteminc" "-isystem" "/opt/LLVM/clangir/llvm/cmake-build-debug/lib/clang/16.0.0/include" "-std=hlsl2021" "-ffp-contract=off" "-fno-experimental-relative-c++-abi-vtables" "-fno-file-reproducible" "-O0" "-fno-emulated-tls" "-fdiagnostics-hotness-threshold=0" "-fdiagnostics-misexpect-tolerance=0"
  (frontend): generated arguments #2 in round-trip: "-cc1" "-verify" "-o" "-" "-fsyntax-only" "-x" "cir" "/opt/LLVM/clangir/clang/test/SemaHLSL/prohibit_pointer.hlsl" "-triple" "dxil-pc-shadermodel6.0-library" "-nostdsysteminc" "-isystem" "/opt/LLVM/clangir/llvm/cmake-build-debug/lib/clang/16.0.0/include" "-O0" "-fno-emulated-tls" "-fdiagnostics-hotness-threshold=0" "-fdiagnostics-misexpect-tolerance=0"

The full list:

Failed Tests (56):
  Clang :: AST/HLSL/RWBuffer-AST.hlsl
  Clang :: AST/HLSL/ResourceStruct.hlsl
  Clang :: AST/HLSL/ast-dump-comment-cbuffe-tbufferr.hlsl
  Clang :: AST/HLSL/cbuffer_tbuffer.hlsl
  Clang :: AST/HLSL/pch.hlsl
  Clang :: AST/HLSL/pch_hlsl_buffer.hlsl
  Clang :: AST/HLSL/pch_with_buf.hlsl
  Clang :: AST/HLSL/resource_binding_attr.hlsl
  Clang :: AST/HLSL/vector-alias.hlsl
  Clang :: AST/HLSL/vector-constructors.hlsl
  Clang :: CodeGenHLSL/GlobalConstructorFunction.hlsl
  Clang :: CodeGenHLSL/GlobalConstructorLib.hlsl
  Clang :: CodeGenHLSL/GlobalConstructors.hlsl
  Clang :: CodeGenHLSL/GlobalDestructors.hlsl
  Clang :: CodeGenHLSL/basic_types.hlsl
  Clang :: CodeGenHLSL/buffer-array-operator.hlsl
  Clang :: CodeGenHLSL/builtins/RWBuffer-annotations.hlsl
  Clang :: CodeGenHLSL/builtins/RWBuffer-constructor.hlsl
  Clang :: CodeGenHLSL/builtins/RWBuffer-subscript.hlsl
  Clang :: CodeGenHLSL/builtins/abs.hlsl
  Clang :: CodeGenHLSL/builtins/create_handle.hlsl
  Clang :: CodeGenHLSL/builtins/sqrt.hlsl
  Clang :: CodeGenHLSL/disable_opt.hlsl
  Clang :: CodeGenHLSL/entry.hlsl
  Clang :: CodeGenHLSL/float3.hlsl
  Clang :: CodeGenHLSL/half.hlsl
  Clang :: CodeGenHLSL/semantics/GroupIndex-codegen.hlsl
  Clang :: CodeGenHLSL/shader_type_attr.hlsl
  Clang :: CodeGenHLSL/validator_version.hlsl
  Clang :: Driver/dxc_D.hlsl
  Clang :: Driver/hlsl_no_stdinc.hlsl
  Clang :: ParserHLSL/access_specifiers.hlsl
  Clang :: ParserHLSL/cb_error.hlsl
  Clang :: ParserHLSL/invalid_inside_cb.hlsl
  Clang :: ParserHLSL/semantic_parsing.hlsl
  Clang :: Preprocessor/predefined-macros-hlsl.hlsl
  Clang :: SemaHLSL/AvailabilityMarkup.hlsl
  Clang :: SemaHLSL/BuiltIns/RWBuffers.hlsl
  Clang :: SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
  Clang :: SemaHLSL/BuiltIns/vector-errors.hlsl
  Clang :: SemaHLSL/GlobalConstructors.hlsl
  Clang :: SemaHLSL/Semantics/entry_parameter.hlsl
  Clang :: SemaHLSL/Semantics/missing_entry_annotation.hlsl
  Clang :: SemaHLSL/Wave.hlsl
  Clang :: SemaHLSL/WaveBuiltinAvailability.hlsl
  Clang :: SemaHLSL/cb_error.hlsl
  Clang :: SemaHLSL/entry.hlsl
  Clang :: SemaHLSL/num_threads.hlsl
  Clang :: SemaHLSL/prohibit_pointer.hlsl
  Clang :: SemaHLSL/prohibit_reference.hlsl
  Clang :: SemaHLSL/resource_binding_attr_error.hlsl
  Clang :: SemaHLSL/shader_type_attr.hlsl
  Clang-Unit :: Driver/./ClangDriverTests/11/13
  LLVM :: tools/llvm-objcopy/ELF/mirror-permissions-unix.test
  MLIR :: Dialect/Math/canonicalize.mlir
  MLIR :: mlir-tblgen/op-attribute.td


Testing Time: 3256.64s
  Skipped          :    69
  Unsupported      : 18986
  Passed           : 64130
  Expectedly Failed:    99
  Failed           :    56

@AlexDenisov
Copy link
Member Author
AlexDenisov commented Oct 7, 2022

Ok, I am on a slightly dated version, this fix does the trick 7da9b77 for HLSL failures, but I'm still seeing the Dialect/Math/canonicalize.mlir and mlir-tblgen/op-attribute.td.

Let me just give a try to the most recent version 😄

@bcardosolopes
Copy link
Member

Hi @AlexDenisov

Let me just give a try to the most recent version 😄

I see the "-fsyntax-only" "-x" "cir" which is indeed suspicious. I'm gonna try this out later and see if I can repro. It's weird because we shouldn't be affecting anything outside clang/test/CIR, so very likely a bug!

@AlexDenisov
Copy link
Member Author

In the end all the tests passed (with the exception of a couple of unrelated failures, see #16 #14).

@bcardosolopes
Copy link
Member

@AlexDenisov does that mean we are safe to add this PR in? I haven't tested the ARM stuff myself, but if you did and everything passes I'm happy to add it to the build instructions.

@AlexDenisov
Copy link
Member Author

Yeah, it seems to be working - at least all the tests pass @bcardosolopes

@bcardosolopes bcardosolopes merged commit c0e373c into llvm:gh-pages Oct 21, 2022
@AlexDenisov AlexDenisov deleted the gh-pages branch October 21, 2022 19:50
lanza pushed a commit that referenced this pull request 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 pull request May 3, 2023
This change prevents rare deadlocks observed for specific macOS/iOS GUI
applications which issue many `dlopen()` calls from multiple different
threads at startup and where TSan finds and reports a race during
startup.  Providing a reliable test for this has been deemed infeasible.

Although I've only observed this deadlock on Apple platforms,
conceptually the cause is not confined to Apple code so the fix lives in
platform-independent code.

Deadlock scenario:
```
Thread 2                    | Thread 4
ReportRace()                |
Lock internal TSan mutexes  |
  &ctx->slot_mtx            |
                            | dlopen() interceptor
                            | OnLibraryLoaded()
                            | MemoryMappingLayout::DumpListOfModules()
                            | calls dyld API, which takes internal lock
                            | lock() interceptor
                            | TSan tries to take internal mutexes again
                            |   &ctx->slot_mtx
call into symbolizer        |
MemoryMappingLayout::DumpListOfModules()
calls dyld API, which hangs on trying to take lock
```
Resulting in:
* Thread 2 has internal TSan mutex, blocked on dyld lock
* Thread 4 has dyld lock, blocked on internal TSan mutex

The fix prevents this situation by not intercepting any of the calls
originating from `MemoryMappingLayout::DumpListOfModules()`.

Stack traces for deadlock between ReportRace() and dlopen() interceptor:
```
thread #2, queue = 'com.apple.root.default-qos'
  frame #0: libsystem_kernel.dylib
  frame #1: libclang_rt.tsan_osx_dynamic.dylib`::wrap_os_unfair_lock_lock_with_options(lock=<unavailable>, options=<unavailable>) at tsan_interceptors_mac.cpp:306:3
  frame #2: dyld`dyld4::RuntimeLocks::withLoadersReadLock(this=0x000000016f21b1e0, work=0x00000001814523c0) block_pointer) at DyldRuntimeState.cpp:227:28
  frame #3: dyld`dyld4::APIs::_dyld_get_image_header(this=0x0000000101012a20, imageIndex=614) at DyldAPIs.cpp:240:11
  frame #4: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::CurrentImageHeader(this=<unavailable>) at sanitizer_procmaps_mac.cpp:391:35
  frame #5: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(this=0x000000016f2a2800, segment=0x000000016f2a2738) at sanitizer_procmaps_mac.cpp:397:51
  frame #6: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::DumpListOfModules(this=0x000000016f2a2800, modules=0x00000001011000a0) at sanitizer_procmaps_mac.cpp:460:10
  frame #7: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::ListOfModules::init(this=0x00000001011000a0) at sanitizer_mac.cpp:610:18
  frame #8: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::FindModuleForAddress(unsigned long) [inlined] __sanitizer::Symbolizer::RefreshModules(this=0x0000000101100078) at sanitizer_symbolizer_libcdep.cpp:185:12
  frame #9: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::FindModuleForAddress(this=0x0000000101100078, address=6465454512) at sanitizer_symbolizer_libcdep.cpp:204:5
  frame #10: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::SymbolizePC(this=0x0000000101100078, addr=6465454512) at sanitizer_symbolizer_libcdep.cpp:88:15
  frame #11: libclang_rt.tsan_osx_dynamic.dylib`__tsan::SymbolizeCode(addr=6465454512) at tsan_symbolize.cpp:106:35
  frame #12: libclang_rt.tsan_osx_dynamic.dylib`__tsan::SymbolizeStack(trace=StackTrace @ 0x0000600002d66d00) at tsan_rtl_report.cpp:112:28
  frame #13: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedReportBase::AddMemoryAccess(this=0x000000016f2a2a90, addr=4381057136, external_tag=<unavailable>, s=<unavailable>, tid=<unavailable>, stack=<unavailable>, mset=0x00000001012fc310) at tsan_rtl_report.cpp:190:16
  frame #14: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ReportRace(thr=0x00000001012fc000, shadow_mem=0x000008020a4340e0, cur=<unavailable>, old=<unavailable>, typ0=1) at tsan_rtl_report.cpp:795:9
  frame #15: libclang_rt.tsan_osx_dynamic.dylib`__tsan::DoReportRace(thr=0x00000001012fc000, shadow_mem=0x000008020a4340e0, cur=Shadow @ x22, old=Shadow @ 0x0000600002d6b4f0, typ=1) at tsan_rtl_access.cpp:166:3
  frame #16: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(void *) at tsan_rtl_access.cpp:220:5
  frame #17: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(void *) [inlined] __tsan::MemoryAccess(thr=0x00000001012fc000, pc=<unavailable>, addr=<unavailable>, size=8, typ=1) at tsan_rtl_access.cpp:442:3
  frame #18: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(addr=<unavailable>) at tsan_interface.inc:34:3
  <call into TSan from from instrumented code>

thread #4, queue = 'com.apple.dock.fullscreen'
  frame #0:  libsystem_kernel.dylib
  frame #1:  libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::FutexWait(p=<unavailable>, cmp=<unavailable>) at sanitizer_mac.cpp:540:3
  frame #2:  libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Semaphore::Wait(this=<unavailable>) at sanitizer_mutex.cpp:35:7
  frame #3:  libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Mutex::Lock(this=0x0000000102992a80) at sanitizer_mutex.h:196:18
  frame #4:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=<unavailable>, mu=0x0000000102992a80) at sanitizer_mutex.h:383:10
  frame #5:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=<unavailable>, mu=0x0000000102992a80) at sanitizer_mutex.h:382:77
  frame #6:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() at tsan_rtl.h:708:10
  frame #7:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __tsan::TryTraceFunc(thr=0x000000010f084000, pc=0) at tsan_rtl.h:751:7
  frame #8:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __tsan::FuncExit(thr=0x000000010f084000) at tsan_rtl.h:798:7
  frame #9:  libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor(this=0x000000016f3ba280) at tsan_interceptors_posix.cpp:300:5
  frame #10: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor(this=<unavailable>) at tsan_interceptors_posix.cpp:293:41
  frame #11: libclang_rt.tsan_osx_dynamic.dylib`::wrap_os_unfair_lock_lock_with_options(lock=0x000000016f21b1e8, options=OS_UNFAIR_LOCK_NONE) at tsan_interceptors_mac.cpp:310:1
  frame #12: dyld`dyld4::RuntimeLocks::withLoadersReadLock(this=0x000000016f21b1e0, work=0x00000001814525d4) block_pointer) at DyldRuntimeState.cpp:227:28
  frame #13: dyld`dyld4::APIs::_dyld_get_image_vmaddr_slide(this=0x0000000101012a20, imageIndex=412) at DyldAPIs.cpp:273:11
  frame #14: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(__sanitizer::MemoryMappedSegment*) at sanitizer_procmaps_mac.cpp:286:17
  frame #15: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(this=0x000000016f3ba560, segment=0x000000016f3ba498) at sanitizer_procmaps_mac.cpp:432:15
  frame #16: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::DumpListOfModules(this=0x000000016f3ba560, modules=0x000000016f3ba618) at sanitizer_procmaps_mac.cpp:460:10
  frame #17: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::ListOfModules::init(this=0x000000016f3ba618) at sanitizer_mac.cpp:610:18
  frame #18: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::LibIgnore::OnLibraryLoaded(this=0x0000000101f3aa40, name="<some library>") at sanitizer_libignore.cpp:54:11
  frame #19: libclang_rt.tsan_osx_dynamic.dylib`::wrap_dlopen(filename="<some library>", flag=<unavailable>) at sanitizer_common_interceptors.inc:6466:3
  <library code>
```

rdar://106766395

Differential Revision: https://reviews.llvm.org/D146593
lanza pushed a commit that referenced this pull request Oct 25, 2023
This crash was exposed recently in our randomized testing. _BitInts were
not being handled properly during IntegerLiteral visitation. This patch
addresses the problem for now.

The BitIntType has no getKind() method, so the FoldingSetID is taken
from the APInt value representing the _BitInt(), similar to other
methods in StmtProfile.cpp.

Crash seen (summary form):

clang-tidy: <src-root>/llvm/include/llvm/Support/Casting.h:566:
decltype(auto) llvm::cast(const From&) [with To = clang::BuiltinType;
From = clang::QualType]: Assertion `isa<To>(Val) && "cast<Ty>() argument
of incompatible type!"' failed

```
  #9 <address> decltype(auto) llvm::cast<clang::BuiltinType,
       clang::QualType>(clang::QualType const&)
       <src-root>/llvm/include/llvm/Support/Casting.h:566:3
 #10 <address> clang::BuiltinType const* clang::Type::castAs<clang::BuiltinType>() const
       <bin-root>/tools/clang/include/clang/AST/TypeNodes.inc:86:1
 #11 <address> (anonymous namespace)::StmtProfiler::VisitIntegerLiteral(
       clang::IntegerLiteral const*)
       <src-root>/clang/lib/AST/StmtProfile.cpp:1362:64
 #12 <address> clang::StmtVisitorBase<llvm::make_const_ptr,
       (anonymous namespace)::StmtProfiler, void>::Visit(clang::Stmt const*)
       <src-root>/clang/include/clang/AST/StmtNodes.inc:1225:1
```

Reviewed By: donat.nagy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants