release-1.6: Backports for Julia 1.6.8#46116
release-1.6: Backports for Julia 1.6.8#46116KristofferC wants to merge 54 commits intorelease-1.6from
Conversation
KristofferC
force-pushed
the
backports-release-1.6
branch
4 times, most recently
from
7a4c4b0 to
2ce254a
Compare
KristofferC
force-pushed
the
backports-release-1.6
branch
from
2ce254a to
7479889
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
@nanosoldier |
This comment was marked as outdated.
This comment was marked as outdated.
|
@nanosoldier |
|
The build failed because gfortran was removed from the package rootfs, https://github.com/JuliaCI/rootfs-images/, resulting in broken triple detection: Notice the wrong filenames, Maybe we can force this using a build flag; let's try: @nanosoldier If that doesn't work I'll deploy a workaround. |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
| } | ||
|
|
||
| #if !defined(_OS_DARWIN_) // xcode already links compiler-rt | ||
|
|
There was a problem hiding this comment.
@KristofferC I'm not sure if you want to merge this commit into your backport or not; it's up to you.
|
The
|
|
I don't know about v1.6, but on master, it is annotated |
|
The windows build now makes it all the way to system image emission, and then dies with an access violation in |
Yes, that was added by you. It looks like on standard |
|
The So this may just be a problem with our earlier LLVM builds. Once again, I think this is just something we didn't run much on 1.6. I'm just going to disable X-ref: JuliaCI/julia-buildkite#272 |
Update: this only happens when we set |
|
Thanks for all your work here @staticfloat! |
|
Bisect points to 93915f8. Manually reverting that on the tip of this branch fixes things. and when I go and look at the original PR, lo and behold, Tim already fixed this in a newer version of LLVM. So I guess the options are we can either bump LLVM version, or we can drop that backport. |
|
Let's drop it then. |
|
The Pkg test failure is that |
|
I have rebased and dropped the two FP16-related commits. |
staticfloat
force-pushed
the
backports-release-1.6
branch
from
42dac39 to
6abbf89
Compare
|
@KristofferC can I leave it to you to deal with the Pkg errors? I think most likely the right thing to do is to backport the |
Co-authored-by: Jameson Nash <vtjnash@gmail.com> (cherry picked from commit 626f3b2)
…`.gitignore` entries (#47952)
This was causing our rewriting of the loader's RPATH emulation to fail after running `make install`, as MSYS2 was rewriting our list that looks like: ``` ../bin/libgcc_s_seh-1.dll:../bin/libopenlibm.dll:@../bin/libjulia-internal.dll:@../bin/libjulia-codegen.dll: ``` Into one that looked like: ``` ..\bin\libgcc_s_seh-1.dll;..\bin\libopenlibm.dll;@..\bin\libjulia-internal.dll;@..\bin\libjulia-codegen.dll; ``` By exporting `MSYS2_ARG_CONV_EXCL='*'` for all `stringreplace` invocations, we dodge this issue, as documented by MSYS2 [0]. [0] https://www.msys2.org/wiki/Porting/#filesystem-namespaces
* Makefile: MSYS2: close path conversion for `DEP_LIBS` Automatic path conversion will replace `:` with `;` * Makefile: MSYS2: use `cygpath` for path convert ref: https://www.msys2.org/docs/filesystem-paths/#manual-unix-windows-path-conversion * devdoc/win/msys2: add build steps * devdoc/win/msys2: Add x86/x64 build notes * devdoc/win/msys2: apply sugestions Co-Authored-By: Elliot Saba <staticfloat@gmail.com> * Instead of `CC_WITH_ENV`, scope environment variables to targets * Fix whitespace Co-authored-by: Elliot Saba <staticfloat@gmail.com>
This allows our `llvm-config.exe` to find its libraries, which is necessary on Windows since there's no `RPATH` support. This was backported as a small piece of 53603f6
Our new CI environment defines environment variables that break this test. We have better behaviors on newer Julia versions.
KristofferC
force-pushed
the
backports-release-1.6
branch
from
bf49963 to
248bef5
Compare
* Generalize Bool parse method to AbstractString Fixes JuliaStrings/InlineStrings.jl#57. We currently have a specialization for `parse(Bool, ::Union{String, SubString{String})` where `true` and `false` are parsed appropriately. The restriction to `Union{String, SubString{String}}`, however, means we don't get this behavior for other `AbstractString`s. In the linked issue above, for InlineStrings, we end up going through the generic integer parsing codepath which results in an `InexactError` when we try to do `Bool(10)`. The proposal in this PR takes advantage of the fact that there is only the 2 comparisons where we do `_memcmp` that require the input string to be "dense" (in memory), and otherwise, we just do a comparison against a `SubString` of the input string. Relatedly, I've wanted to introduce the concept of an abstrac type like: ```julia abstract type MemoryAddressableString <: AbstractString ``` where the additional required interface would be being able to call `pointer(::MemoryAddressableString)`, since a lot of our string algorithms depend on doing these kind of pointer operations and hence makes it quite a pain to implement your own custom string type. * Apply suggestions from code review Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> (cherry picked from commit 63830a6)
(cherry picked from commit 6d678fe)
The dynamic linker needs to unify `llvm::Any::TypeId` across DSOs. In our case `libjulia-codegen` and `libLLVM`. See https://github.com/llvm/llvm-project/blob/2bc4c3e920ee078ef2879b00c40440e0867f0b9e/llvm/include/llvm/ADT/Any.h#L30 Fixes: #49121 (cherry picked from commit d8fa3c8)
(cherry picked from commit 1eee6ef)
(cherry picked from commit 432f300)
KristofferC
force-pushed
the
backports-release-1.6
branch
from
7b0c91b to
fb2fd0b
Compare
|
Is the libcurl CVE serious? libcurl is not just for Pkg, also Downloads? I.e. should this just be released, as possibly, the last 1.6 LTS? I did not look carefully at the errors (false alarms?):
|
|
Simply close this because of new TLS? Or release last point release for some reason (anyone stuck on 1.6.x)? |
|
@PallHaraldsson IMHO yes, simply close. |
|
@KristofferC Please close [to avoid any possible confusion]. Cross reference: |
20 participants
Backported PRs:
Tridiagonal/SymTridiagonalare empty #42574Base.stale_cachefile: allowftime_reqto be greater thanftimeby up to one microsecond (to compensate for Windows tar) #45552reverse!#45871BLAS.[sy/he]mm!#45605BUILDKITE_BRANCHto provide branch name #46053copyto!fix forBitArray/AbstractArray#46161leqfor reals falls back toleandeq#46341PhiNodewithedge==0#46388intersection = 1duringintersect_sub_datatype#46882expanduserthrowing #47058globalexpressions #47719OPENBLAS_NUM_THREADS=1on local Distributed workers #47803p7zipurl #48176Need manual backport:
jl_setjmpon windows #42267dotfor 1x1 structured matrices #46473elseifand short-circuit op #47499hash(::Type, ::UInt)#49636BigFloat#49909Contains multiple commits, manual intervention needed:
default_rngand remove references toGLOBAL_RNG#44733pinv#45009hash(::BigInt)on 32 bit systems #50076SuiteSparse_jll: onlydlopenthe libraries ifBase.USE_GPL_LIBSis true #50267expm1(::Union{Float16, Float32})#50989Non-merged PRs with backport label:
cwstringwhen used for env lookup / modification on Windows #51371transposeinLinearAlgebra.copy_transpose!to handle matmul of isbits array-elements with non-identity transpose #42715