[PATCH] D127593: [clang] Fix trivially copyable for copy constructor and copy assignment operator

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D127593#3590072 <https://reviews.llvm.org/D127593#3590072>, @Javier-varez wrote:

> I did try this locally and the built test binaries seem to crash with a segmentation fault. I run one of them in lldb to check the error and I got this backtrace:
>
>   llvm-project/build on  fix-trivially-copyable-check [?⇕] via △ v3.22.3 took 3s ❯ lldb /Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp
>   (lldb) target create "/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp"
>   Current executable set to '/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp' (arm64).
>   (lldb) r
>   Process 61339 launched: '/Users/javier/Desktop/Projects/llvm-project/build/projects/openmp/runtime/test/worksharing/single/Output/omp_single_copyprivate.c.tmp' (arm64)
>   Process 61339 stopped
>   * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
>       frame #0: 0x0000000100362f54 libomp.dylib`::__kmp_get_global_thread_id() at kmp_runtime.cpp:201:8
>      198
>      199 	  /* dynamically updated stack window for uber threads to avoid get_specific
>      200 	     call */
>   -> 201 	  if (!TCR_4(other_threads[i]->th.th_info.ds.ds_stackgrow)) {
>      202 	    KMP_FATAL(StackOverflow, i);
>      203 	  }
>      204
>   Target 0: (omp_single_copyprivate.c.tmp) stopped.
>   (lldb) bt
>   * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
>     * frame #0: 0x0000000100362f54 libomp.dylib`::__kmp_get_global_thread_id() at kmp_runtime.cpp:201:8
>       frame #1: 0x00000001003b8c60 libomp.dylib`void __kmp_release_template<kmp_flag_64<false, true> >(flag=0x000000016fdff0b8) at kmp_wait_release.h:790:39
>       frame #2: 0x00000001003b8c20 libomp.dylib`::__kmp_release_64(flag=0x000000016fdff0b8) at kmp_wait_release.cpp:25:46
>       frame #3: 0x00000001003798d0 libomp.dylib`__kmp_reap_thread(thread=0x0000000101010a40, is_root=0) at kmp_runtime.cpp:6146:9
>       frame #4: 0x000000010037497c libomp.dylib`__kmp_internal_end() at kmp_runtime.cpp:6334:7
>       frame #5: 0x00000001003745ec libomp.dylib`::__kmp_internal_end_library(gtid_req=-1) at kmp_runtime.cpp:6498:3
>       frame #6: 0x0000000100374258 libomp.dylib`::__kmp_internal_end_atexit() at kmp_runtime.cpp:6115:3
>       frame #7: 0x0000000100374218 libomp.dylib`::__kmp_internal_end_dtor() at kmp_runtime.cpp:6083:3
>       frame #8: 0x0000000189359dc4 libsystem_c.dylib`__cxa_finalize_ranges + 464
>       frame #9: 0x0000000189359b68 libsystem_c.dylib`exit + 44
>       frame #10: 0x000000018947aec4 libdyld.dylib`dyld4::LibSystemHelpers::exit(int) const + 20
>       frame #11: 0x00000001000150d4 dyld`start + 592
>   (lldb)
>
> Not sure how to proceed from here though... I'm really not familiar with OpenMP

If you remove your patch, does the OMP failure still happen?  Or does this patch cause it?  If so, you might find that you need to see the difference between the two generated executables and see if something obvious has changed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127593/new/

https://reviews.llvm.org/D127593