RWTH Aachen University
- User Since
- Apr 2 2015, 4:52 AM (202 w, 4 d)
LG if that fixes the problem. For the record llvm/runtimes/ does the same.
Sun, Feb 17
@phosek Sorry for the breakage. I guess there are just too many configurations for non-trivial changes to the build system :-/
I needed to push rCRT354231 to fix the sanitizer bots. Let me know if this change is appropriate or want me to revert. In that case we need to run another round of clobber builds to fix CMake configuration (needed because the patch changes the source directory for ExternalProject_Add).
Sat, Feb 16
Fri, Feb 15
Revert changes to CMAKE_THREAD_LIBS_INIT.
I had to revert this in r354153 because it breaks sanitizer-x86_64-linux:
Thu, Feb 14
Cleaunup CustomLibcxx/CMakeLists.txt and build custom libcxx without exceptions.
Wed, Feb 13
@phosek Excellent idea. I tried to implement what you described and it seems to work great! The only minor disadvantage is that we now need to disable the tests if COMPILER_RT_LIBCXXABI_PATH is not found...
Rebase, apply the same treatment to TSan, and rename option to SANITIZER_TEST_CXX.
Mon, Feb 11
Sun, Feb 10
Sat, Feb 9
Fri, Feb 8
Thu, Feb 7
As said in D57851, this will not handle Clang and only work for GCC.
Sat, Jan 26
I think it's a good idea to have a proper RFC on cfe-dev about how to handle runtime libraries in case they are already installed in system directory. More pointers on historic discussions below.
Fri, Jan 25
Thu, Jan 24
I think this patch would effectively lose the ability to use a custom standalone build of the OpenMP runtime: When hacking on the runtime it's pretty convenient to only build and install the openmp repository and use environment variables to switch between different versions. When putting libomp.so into lib/clang/9.0.0/lib/linux/x86_64  this path will be very first one that Clang instructs the linker to look at. As a result the "custom" location that I specify in LIBRARY_PATH won't be honored and I'll always end up using the version installed next to the compiler.
Jan 4 2019
I don't know anything about GlobalISel implementation. The patch seems to do the right thing, but I'll defer to somebody who knows the code.
Yeah, sorry about that: That message was before I got the chance to really look into the generated assembly. I posted my analysis in the referenced bug you reported (https://bugs.llvm.org/show_bug.cgi?id=40131#c6) and frameaddress is also missing from GlobalISel which is why some tests are still failing. Fortunately there is https://reviews.llvm.org/D56266 which should restore -fno-experimental-isel and turn all tests green again until somebody has time to fully address all issues related to GlobalISel.
Jan 3 2019
I think you should also revert the other changes from rL349512.
Jan 2 2019
Did you also implement frameaddress in GlobalISel (see llvm.org/PR40131)? Otherwise this won't make all tests work and it would be better to "fix" -fno-experimental-isel.
Thanks for the explanation, that sounds useful.
Dec 28 2018
Can you explain the benefit of this change? I would have expected a target like install-omptarget, but applying this patch locally didn't change anything visible.
Dec 18 2018
Dec 17 2018
Dec 9 2018
I think there was a discussion in the past whether it makes sense to allow building for an older version of the standard, given that the library guarantees backwards compatibility. Your findings once again show that nobody is even compile-testing the old code, so I think it would be best to just remove all the #ifdefs and code that is not needed anymore. For everything else there's a version control system that you can ask about old versions of the code.
Dec 5 2018
I think there are some misunderstandings here, or at least I understand things differently than @tra is describing them: AFAICS this change is NOT about replacing nvcc by clang in any CMake project (be that the OpenMP runtime or any other project outside of LLVM). The scope of the second issue is that there is a CMake project (namely openmp) which uses FindCuda.cmake to detect the CUDA installation and passes the resulting path to --cuda-path. I wrote that detection and I still think it's correct because that is a way to force Clang to use a given CUDA install location. If FindCuda.cmake returns a wrong path (/usr instead of /usr/lib/cuda) or the shim package behind /usr/lib/cuda is incomplete, then this needs to be fixed and not workarounded in Clang.
Dec 4 2018
Ah, this packaging style is a never ending source of fun... Adding isUbuntu() seems fine to solve the first issue.
Oct 14 2018
As said on D53250 I think this is the right way to fix these tests: We already do the same for -stdlib=platform and -rtlib=platform.
If I read that patch correctly, this will render -fuse-ld with non-absolute paths useless if a toolchain has DefaultLinker != "ld". I don't think that's what we want to do if the user explicitly sets a different linker.
Oct 11 2018
I guess this will break the case when the DataSize passed to __kmpc_data_sharing_push_stack() needs additional alignment: With this change it is handled in data_sharing_push_stack_common() but __kmpc_data_sharing_push_stack() will determine PushSize without the adjustment and do the final pointer arithmetic.
Oct 9 2018
Oct 5 2018
Out of interest: Is this fixing a particular issue?