- User Since
- Apr 15 2014, 12:19 PM (261 w, 3 d)
Tue, Apr 9
Fri, Apr 5
Wed, Apr 3
Tue, Apr 2
- Only set OPENMP_TEST_COMPILER_OPENMP_FLAGS once.
- For standalone builds, call find_package(Threads) and use the result unconditionally.
- Fix else -> else().
Mon, Apr 1
So, any thoughts on the current state of the review?
Mon, Mar 25
Sun, Mar 24
- Use CMAKE_THREAD_LIBS_INIT verbatim, if it is not "-lpthread".
- Add similar logic to DetectTestCompiler for standalone build.
Readdress the issue in a different way: add -pthread in the
OpenMPTesting.cmake file instead. The top-level LLVM config-ix.cmake file
mangles the value of the needed CMAKE_THREAD_LIBS_INIT variable, so derive the
flag from this, instead of directly using it.
Sat, Mar 23
Using CMake's own FindThreads package is obviously the correct solution for finding the right compiler and linker options for enabling threading.
Mar 17 2019
Mar 16 2019
Update to use -pthread instead.
Mar 11 2019
Btw @jonpa, for me it's still interesting as to why the compiler hang only occurred for builds targeting i386 (i.e 32 bit x86), while x86_64 worked just fine. Is it due to the lower number of physical registers on i386?
@hans it's really late but if you're going to spin 8.0.0 rc5, it would be nice if this one gets merged too, after it's been committed. Or if not, I'll probably merge into the FreeBSD version of clang anyway, since we hit this issue first. :)
This helps quite a lot, in the sense that my original test case from PR40986 now at least compiles within a finite time. There is still a performance loss between clang 7.0.1 and clang 8.0.0 with this patch, though (tested with 10 runs each):
Mar 6 2019
Feb 27 2019
Feb 20 2019
I will update and commit.
In the case of <__locale>, __throw_runtime_error is already used in the file before its declaration, but via transitive includes, <stdexcept> is also included earlier, so it gets the duplicate declaration of __throw_runtime_error from there. I think we can just delete the __throw_runtime_error declaration from <__locale> altogether.
Feb 6 2019
Feb 5 2019
For what it's worth, this builds and tests correctly for me, and also appears to solve the test cases from bug 40206.
Jan 29 2019
Updated as @ruiu suggested.
Updated to address comments:
- Replaced tuple with BfdDesc struct
- Parse -freebsd suffix to determine OSABI
- Add new case for elf-aarch64 (which used to be elf-aarch64-freebsd)
Jan 28 2019
Jan 26 2019
Jan 25 2019
Jan 24 2019
Jan 20 2019
I can't vouch for the NetBSD part, but this definitely seems like a good idea to me. I'm unsure if the sysctl is already fixed on the FreeBSD side. @emaste any idea?
Jan 7 2019
Dec 25 2018
I'm not sure yet why, but this revision breaks unrolling of some loops in FreeBSD's lib/msun/ld80/e_powl.c, specifically the one in __polevll here, which gets expanded in two places, one instance with a count of 3:
Dec 23 2018
Dec 20 2018
Dec 16 2018
Nov 20 2018
Nov 19 2018
I think this is the wrong direction, placing "common" code in addCXXStdlibLinkDeps, which then has all kinds of ugly ifs and switches for different OSes? Let different OSes handle this in their own way, maybe.
Nov 18 2018
On FreeBSD, there is no libterminfo either, so LGTM.
Oct 22 2018
Oct 11 2018
Oct 8 2018
Here is the shortest test case I could come up with. (This uses ld.lld-r325886, but it could also use ld.lld 6.0.1.)
Oct 6 2018
Oct 2 2018
Oct 1 2018
This change breaks booting an lld-linked i386-freebsd kernel, apparently because it moves symbols around, while not updating the sections? For instance, with lld r325886, I have the following readelf output:
Sep 22 2018
Ah, sorry about that! I should have realized this, but my CMake-fu is weak. :)
Sep 21 2018
Sep 18 2018
Built with mkdir build && cd build && cmake -G Ninja .. && ninja, the resulting libc++.so.1 has the following additional symbols:
Sep 16 2018
So, any more actions to take, or can I commit this?
Sep 1 2018
Aug 29 2018
Aug 28 2018
Update all tests to match current output.
Aug 15 2018