I would like to nominate bug 26040, bug 26074 and bug 26081. There is also still the case of the libc++ cout alignment increase problem (see [1] and [2]), for which I will submit a new bug, which is a release blocker, at least for FreeBSD. :) [1] http://lists.llvm.org/pipermail/cfe-dev/2015-October/045410.html [2] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160104/322346.html
I would like to nominate bug 23529 . Arch Linux has switched to using the new libstdc++ ABI and upstream Clang doesn't work correctly with it. The Arch linux devs are currently applying the patch at http://reviews.llvm.org/D12834 but apparently it's not yet complete. It would also be much nicer if this was fixed in upstream.
Also bug 26136 is an example of the many regressions introduced in the openmp support just before the branching of 3.8 occurred causing many new regressions in both the OpenMP's own libomp test suite and the OpenMP3.1_Validation test suite.
Bug 26136 in 3.8 branch should be fixed by applying r257925, r257929 and r257930. The r257997 commit should also be back ported to prevent the libomp test suite failures, currently latent in 3.8 branch, from being exposed by additional back ports from trunk. ------------------------------------------------------------------------ r257925 | mren | 2016-01-15 14:35:42 -0500 (Fri, 15 Jan 2016) | 10 lines CXX_FAST_TLS calling convention: fix issue on X86-64. When we have a single basic block, the explicit copy-back instructions should be inserted right before the terminator. Before this fix, they were wrongly placed at the beginning of the basic block. I will commit fixes to other platforms as well. PR26136 ------------------------------------------------------------------------ r257929 | mren | 2016-01-15 15:13:28 -0500 (Fri, 15 Jan 2016) | 10 lines CXX_FAST_TLS calling convention: fix issue on AArch64. When we have a single basic block, the explicit copy-back instructions should be inserted right before the terminator. Before this fix, they were wrongly placed at the beginning of the basic block. I will commit fixes to other platforms as well. PR26136 ------------------------------------------------------------------------ r257930 | mren | 2016-01-15 15:24:11 -0500 (Fri, 15 Jan 2016) | 8 lines CXX_FAST_TLS calling convention: fix issue on ARM. When we have a single basic block, the explicit copy-back instructions should be inserted right before the terminator. Before this fix, they were wrongly placed at the beginning of the basic block. PR26136 ------------------------------------------------------------------------ r257997 | mren | 2016-01-16 11:39:46 -0500 (Sat, 16 Jan 2016) | 12 lines CXX_FAST_TLS calling convention: fix issue on x86-64. %RBP can't be handled explicitly. We generate the following code: pushq %rbp movq %rsp, %rbp ... movq %rbx, (%rbp) ## 8-byte Spill where %rbp will be overwritten by the spilled value. The fix is to let PEI handle %RBP. PR26136
Per comment 1, adding bug 26040, bug 26074 and bug 26081 as blockers.
Adding bug 26134 as this is a pretty nasty regression.
The following recent OpenMP fixes to cfe should be considered for back porting to 3.8 branch... Author: abataev Date: Wed Jan 20 06:29:47 2016 New Revision: 258307 URL: http://llvm.org/viewvc/llvm-project?rev=258307&view=rev Log: [OPENMP 4.0] Fix for codegen of 'cancel' directive within 'sections' directive. Allow to emit code for 'cancel' directive within 'sections' directive with single sub-section. Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp cfe/trunk/test/OpenMP/cancel_codegen.cpp Author: abataev Date: Thu Jan 21 06:35:58 2016 New Revision: 258394 URL: http://llvm.org/viewvc/llvm-project?rev=258394&view=rev Log: [OPENMP] Fix crash on reduction for complex variables. reworked codegen for reduction operation for complex types to avoid crash Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp cfe/trunk/lib/CodeGen/CodeGenFunction.h cfe/trunk/test/OpenMP/parallel_reduction_codegen.cpp Author: abataev Date: Thu Jan 21 06:54:48 2016 New Revision: 258396 URL: http://llvm.org/viewvc/llvm-project?rev=258396&view=rev Log: Fix crash for typedefs for arrays of runtime bounds in Lambdas/Captured Statements, used in sizeof() expression only. Modified: cfe/trunk/lib/Sema/SemaExpr.cpp cfe/trunk/test/CodeGenCXX/lambda-expressions.cpp
I would like to propose Bug 26348 to improve AArch64 support for half floats. This support was very broken in branch 3.7. https://llvm.org/bugs/show_bug.cgi?id=26348
The following change seems like a candidate for back-porting if the current behavior is incorrect. Author: jlpeyton Date: Wed Jan 27 15:20:26 2016 New Revision: 258990 URL: http://llvm.org/viewvc/llvm-project?rev=258990&view=rev Log: Restore th_current_task first as suggested by John Mellor-Crummey If an asynchronous inquiry peers into the runtime system it doesn't see the freed task as the current task. Modified: openmp/trunk/runtime/src/kmp_tasking.c
(In reply to comment #8) > I would like to propose Bug 26348 to improve AArch64 support for half > floats. This support was very broken in branch 3.7. > https://llvm.org/bugs/show_bug.cgi?id=26348 Thanks. I've replied on the r258471 thread. (In reply to comment #9) > The following change seems like a candidate for back-porting if the current > behavior is incorrect. > > Author: jlpeyton > Date: Wed Jan 27 15:20:26 2016 > New Revision: 258990 > > URL: http://llvm.org/viewvc/llvm-project?rev=258990&view=rev > Log: > Restore th_current_task first as suggested by John Mellor-Crummey Thanks. I've replied on the thread.
I'd like to nominate bug 26369. It introduces several regressions in the std/atomic tests for 32-bit MIPS. There's a review request pending (see http://reviews.llvm.org/D16613), that fixes the problem.
(In reply to comment #11) > I'd like to nominate bug 26369. It introduces several regressions in the > std/atomic tests for 32-bit MIPS. There's a review request pending (see > http://reviews.llvm.org/D16613), that fixes the problem. Thanks, I'll keep an eye on that patch.
I would like to nominate r259332 which is the fix bug 26392 and allows a functional Polly to be built on darwin with -DBUILD_SHARED_LIBS:BOOL=ON.
I would like to nominate the two pending fixes for bug 26393 when they land in trunk for back porting to 3.8 branch. The fix proposed in https://llvm.org/bugs/show_bug.cgi?id=26393#c22 (which is the aggregate of the suggestions from Chris in https://llvm.org/bugs/show_bug.cgi?id=26393#c17 and https://llvm.org/bugs/show_bug.cgi?id=26393#c20) eliminates the erroneous extra linkage of llvm component static libraries, which make up libLLVM.dylib, when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is used. The polly patch proposed in https://llvm.org/bugs/show_bug.cgi?id=26393#c23 makes the build of LLVMPolly.so aware of LLVM_LINK_LLVM_DYLIB so that the individual LLVM component shared library linkages are replaced with a single linkage on libLLVM.dylib in that case. The two patches applied to 3.8 branch passes a 3-stage bootstrap with stage 2 and 3 file comparison and exhibit no regressions in the test suites as seen from https://llvm.org/bugs/show_bug.cgi?id=26393#c24.
I would like to nominate bug 26433 as it breaks LLVM build with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON. Proposed patch is attached to the bug.
(In reply to comment #15) > I would like to nominate bug 26433 as it breaks LLVM build with -D > LLVM_USE_INTEL_JITEVENTS:BOOL=ON. Proposed patch is attached to the bug. Thanks, I will consider it for 3.8 if the patch lands soon. I'm not sure who'd be a good reviewer for your patch - IntelJITEventListener doesn't seem to get a lot of changes. Maybe Elena or someone else from Intel could review it?
I would like to nominate r259659 which is the fix to properly link LLVMPolly.so against libLLM when LLVM_LINK_LLVM_DYLIB is enabled.
(In reply to comment #17) > I would like to nominate r259659 which is the fix to properly link > LLVMPolly.so against libLLM when LLVM_LINK_LLVM_DYLIB is enabled. Tobias merged it earlier today.
I would like to nominate fixing bug 26393 by applying r260641 so that the new LLVM_LINK_LLVM_DYLIB cmake option for building and linking the tools against a unified libLLVM dynamic library is usable in 3.8.0. ------------------------------------------------------------------------ r260641 | axw | 2016-02-11 20:42:43 -0500 (Thu, 11 Feb 2016) | 10 lines Avoid linking LLVM component libraries with libLLVM Patch by Jack Howarth. When linking to libLLVM, don't also link to the component libraries that constitute libLLVM. Differential Revision: http://reviews.llvm.org/D16945
I'd like to nominate r260370. It fixes crash of clang in some cases with incomplete record types
Bug 26369, which has been fixed with r260961, requires the following commits to get merged on the release branch: - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic." - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so they don't clash with LLVM - [libcxx] r260961 - Issue a warning instead of fatal errors when checks for libatomic fail.
(In reply to comment #21) > Bug 26369, which has been fixed with r260961, requires the following commits > to get merged on the release branch: > > - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out > whether we need to link with libatomic." > - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes > - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so > they don't clash with LLVM > - [libcxx] r260961 - Issue a warning instead of fatal errors when checks for > libatomic fail. I've been following this series of patches, and also the thread on r260235. There's too much churn here too late in the process, it sounds like there might be issues even after the last patch(?), and even then, mclow would need to approve them all for the branch. While certainly nice to have, I'm not sure these fixes are addressing 3.7 regressions (did these tests pass on 3.7)?
Back porting r261148 to 3.8 branch... Author: samsonov Date: Wed Feb 17 14:40:10 2016 New Revision: 261148 URL: http://llvm.org/viewvc/llvm-project?rev=261148&view=rev Log: [TSan] PR26609: Fix two test cases. Modified: compiler-rt/trunk/test/tsan/ignore_lib0.cc compiler-rt/trunk/test/tsan/printf-1.c eliminates two test suite failures on darwin.
> I've been following this series of patches, and also the thread on r260235. There's too much churn here too late in the process, it sounds like there might be issues even after the last patch(?), and even then, mclow would need to approve them all for the branch. There are still major issues with these changes. I'm personally don't want these changes merged into 3.8 this late in the release process. However I'll work with the patch authors to get it working in trunk and defer to mclow about wither to merge them.
The updated list of commits around CheckLibcxxAtomic.cmake - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic." - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so they don't clash with LLVM - [libcxx] r260961 - Issue a warning instead of fatal errors when checks for libatomic fail. - [libcxx] r261383 - Fix PR26622 - Make CheckLibcxxAtomic.cmake use the libc++ headers.