Backports for Julia v0.6.3 #26915
Backports for Julia v0.6.3 #26915
Conversation
Should allow files >2 GB to be truncated on Windows. Fix #24466 Checking Windows 32bit build https://julialang-s3.julialang.org/bin/winnt/x86/0.6/julia-0.6.1-win32.exe, libgit2.dll already uses `_chsize_s`, so both 32bit and 64bit should be able to use `_chsize_s`. Ref #24616 (cherry picked from commit ff045af)
Computes the dependency graph subset induced by the requirements after filter_versions has propagated the implicit requirements, rather than before, which ensures that only the parts reachable from some requirement are kept. In practice, it removes many more useless parts of the graph. (Plus other tiny improvements.) Ref #24904 (cherry picked from commit 9b00059)
|
@nanosoldier |
ararslan
force-pushed
the
aa/backports-0.6.3
branch
from
e28fa23 to
d63500f
Compare
|
Tests are looking good on Linux and Windows, but there seems to be a problem with the macOS build: Any ideas, @staticfloat? Maybe an issue with the tap? |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
|
Do we have anything to test whether the GPU infrastructure will keep working on 0.6.3? @nishanth @aviks @maleadt @MikeInnes |
|
CUDAdrv/LLVM/CUDAnative/CuArrays test fine on this branch right now. |
|
@nanosoldier |
|
Does this need to be backported? #25537 |
|
Julia 0.6 doesn't carry other patches for LLVM versions after 3.9.1; I don't think we supported later versions in 0.6, in which case backporting that would be unnecessary. I could be wrong though. @vchuravy? |
|
Indeed, the support LLVM version is 3.9.1 and I think we shouldn't backport patches for versions that we didn't even have developmental support. @iblis17 to have a particular reason for wanting to backport that patch? Are you using Julia 0.6 with LLVM 4.0.0? |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
|
@vchuravy oh okay, I'm fine with not to backporting it. |
|
FreeBSD CI build is here: https://freebsdci.julialang.org/#/builders/1/builds/9129 |
|
FreeBSD CI got segfault 🤔 |
|
Looks like the hashing tests caused a segfault on FreeBSD. I can't reproduce that locally. @iblis17, can you? |
|
I can access the core file, it points to I'm building this brach on local... |
|
@iblis17 Any update on your end? Building this branch on FreeBSD 11.1 after |
|
I don't get segfault locally also. |
|
FreeBSD CI passed now. |
|
Great, thanks for confirming! Once PackageEvaluator finishes this should be good to go (assuming all's well there). |
FreeBSD's system libgcc_s declares its GCC version as 4.6, which is too old to build Julia. Since gfortran doesn't come installed by default, when it's installed it's done so through a GCC port, which includes its own libgcc_s. Linking to libgfortran from the port and to the system's libgcc_s causes versioning issues which wreck the build. This commit works around this issue by determining the version of GCC used for gfortran, then linking in the libgcc_s corresponding to that version everywhere. It's a bit of a kludge, but it gets the job done. With this change, all libraries which need to link to libgcc_s link to the proper version. Ref #21788 (cherry picked from commit 7d83d99)
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See #19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496 Ref #25597 (cherry picked from commit edabf42)
…pect inference to be non-terminating this same issue applied to several other similar functions similarly, need to avoid nesting the use of functional code (like map) too deeply inside the array code to avoid the appearance of indeterminate recursion in inference (minimally cherry-picked just for base/array.jl from 4f1b479
ararslan
force-pushed
the
aa/backports-0.6.3
branch
from
6981b0c to
2583e04
Compare
|
I've removed the commit from #26897 to see whether that fixes the permissions error on Windows. That PR was the first time it was observed, even though the change looks entirely unrelated. |
|
Well, I can't explain why, but removing that commit seems to have fixed it. |
|
Looks like there's a network issue or something with the i686 Linux build on Travis; it keeps getting checksum mismatches then rebuilding everything. I'm not sure why it would only happen for i686 though, as the x86-64 build works fine... |
|
The branch cache probably got polluted with master somehow. That happened when I did 0.6.2 as well. Since Travis is trying to rebuild everything I'm just going to stop it since it will just eat into our CI time just to eventually time out. So this PR should be good to merge I think. |
Still to do:
nothingused as a key #26839: Needs more careful application to the release branch, since the changes make use of changes that were not backported. @vtjnashNext steps:
Omitted:
Changes to allow building on FreeBSD, also omitted from 0.6.1 and 0.6.2. I tried backporting them this time but wasn't able to get things working, so unless someone has a vested interest in first-class FreeBSD support for 0.6.3, I'll leave them out of this release as well.0.6.3 will have FreeBSD support.