[GIAC] Bump to v2.0.2 — GIAC_TYPE_ON_8BITS default, align GCC to v10, enable GSL/LAPACK/GLPK#13717
Draft
s-celles wants to merge 7 commits into
Draft
[GIAC] Bump to v2.0.2 — GIAC_TYPE_ON_8BITS default, align GCC to v10, enable GSL/LAPACK/GLPK#13717s-celles wants to merge 7 commits into
s-celles wants to merge 7 commits into
Conversation
Pins to s-celles/giac@64fdcefb (PR #1 on that fork, merged into dev) which sets GIAC_TYPE_ON_8BITS=1 by default in dispatch.h, replacing the historical `type:5 + type_unused:3` bitfield in `class gen` with a plain 8-bit `unsigned char`. The default ships through the installed header so every consumer of GIAC_jll sees the same gen layout libgiac.so was compiled with — no implicit "remember to -D the macro too" contract. The bitfield form was access-fused differently by GCC 8 vs GCC 10, producing a real ABI bug in the downstream JLL pair: a gen tagged _REAL by libgiac (built here with GCC 8) was read back as _DOUBLE_ by libgiac_julia_jll (GCC 10), breaking MPFR float conversions on Windows (Giac.jl#22, libgiac-julia-wrapper#5 investigation). Two coordinated changes prevent regressions of the same class: 1. New giac default replaces the bitfield with a full byte — compiler-invariant layout regardless of fusion choices. 2. preferred_gcc_version bumped 8 → 10 to match libgiac_julia_jll's recipe. Cost noted by giac's author: 3 mantissa bits on inline doubles encoded in a gen (48 → 45). sizeof(gen) unchanged. Verified: - Built locally on x86_64-linux-gnu-cxx11 in 4m13s, all 3 products (libgiac, icas, aide_cas) produced. - giac's own CI green on Linux, macOS, Windows MSYS2 post-merge (unit + integration tests).
Switch -Dgsl from disabled to enabled and add GSL_jll 2.8.1 as a dependency. Validated by a clean cross-build for x86_64-linux-gnu; icas and libgiac.so auto-map to libgsl.so.28 and libgslcblas.so.0 from GSL_jll.
Switch -Dlapack from disabled to enabled and add OpenBLAS32_jll
(LP64 ABI) plus CompilerSupportLibraries_jll as dependencies.
OpenBLAS_jll itself is ILP64 with _64_ symbol suffixes that Giac
does not expect.
Meson's dependency('blas')/dependency('lapack') only look for
blas.pc/lapack.pc; the script now drops self-contained wrappers
in ${prefix}/lib/pkgconfig before meson setup (skipped on macOS,
where Giac picks up the Accelerate framework).
Validated by a clean cross-build for x86_64-linux-gnu; eigenvals
on a 300x300 float matrix completes in ~70 ms (vs seconds without
LAPACK).
Switch -Dglpk from disabled to enabled and add GLPK_jll 5.0.1 as a
dependency. GLPK_jll ships no pkg-config file, so the script drops
a self-contained glpk.pc in ${prefix}/lib/pkgconfig before meson
setup.
Validated by a clean cross-build for x86_64-linux-gnu; libgiac.so
auto-maps to libglpk.so.40 and lpsolve returns the expected
optima on small LP test problems.
GLPK_jll doesn't ship a riscv64 binary, so building Giac with -Dglpk=enabled fails on those targets. Gate the GLPK option (and the glpk.pc shim) behind a target check so riscv64 falls back to -Dglpk=disabled while every other platform keeps GLPK enabled.
Restrict GLPK_jll to platforms that ship artifacts, mirroring the GLPK_OPT=disabled branch in the script.
Contributor
Author
|
#13754 should probably be considered before this. So marking this one as draft |
GLPK_jll now ships riscv64-linux-gnu artifacts (JuliaPackaging#13754), so drop the platform filter and conditional and bump compat to 5.0.2.
s-celles
changed the title
Contributor
Author
|
#13771 should also be considered before this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GIAC_jlltov2.0.2.s-celles/giac@64fdcefb, the new tip of the fork'sdevbranch, which defaultsGIAC_TYPE_ON_8BITS=1insrc/dispatch.h. That replaces the historicalunsigned char type:5; unsigned char type_unused:3;bitfield inclass genwith a plainunsigned char type;.preferred_gcc_versionfromv"8"tov"10"to matchlibgiac_julia_jll's recipe.Why
The bitfield layout was access-fused differently across GCC versions. GCC's optimizer combines adjacent bitfield writes (
g.type = ...; g.subtype = ...;) into a wider store using version-dependent bit placements. GCC 8 (currentGIAC_jll) and GCC 10 (libgiac_julia_jll) disagree on which bits holdtype, which produces a real user-visible ABI bug downstream:libgiac.sowrites agentagged_REAL(3)libgiac_julia_jll(the CxxWrap wrapper) reads it back and sees_DOUBLE_(1)evalf(pi, 50)returned byGiac.jlis mis-tagged, breakingfloat()and other conversions. Tracking ins-celles/Giac.jl#22.A multi-platform C++ probe (investigation in
s-celles/libgiac-julia-wrapper#5) ran with both modes (bitfield default vs-DGIAC_TYPE_ON_8BITS) on Linux GCC 12, macOS clang, and Windows MSYS2 GCC 15.2. Same-compiler builds produced correct_REALtagging in both modes; the bug only manifests when libgiac and consumer were compiled with different GCC versions — exactly the production scenario.With
GIAC_TYPE_ON_8BITS=1, thetypefield is a plain byte at offset 0; both GCC 8 and GCC 10 emit a trivial byte store/load. No fusion, no version-dependent packing. The ABI becomes compiler-invariant.The macro is set in
dispatch.h(which is installed alongsidegen.h), so every consumer ofGIAC_jllautomatically sees the same layoutlibgiac.sowas compiled with — no implicit "remember to-Dit on your side too" contract.Cost
3 bits of mantissa lost on inline doubles stored within a
gen(48 → 45).sizeof(gen)unchanged at 64 bits.Coordinated downstream change
L/libgiac_julia/build_tarballs.jlshould be bumped after this PR lands to pick up the newGIAC_jllABI. The pinned commit there (s-celles/libgiac-julia-wrapper@490207923b75678ace5409e16ed5bc134bd9c7d9) doesn't need to change — only the version and theGIAC_jllcompat range. I'll open that follow-up PR after this one merges.Verification
julia build_tarballs.jl --verbose --deploy=local x86_64-linux-gnu-cxx11→ success in 4m13s, all 3 products (libgiac.so,icas,share/giac/aide_cas) produced; audit clean; libstdc++ auto-detected to system (GCC 10 ABI).Test plan (for CI here)