llvm35 doesn't like generational GC

[vtjnash]

jameson@julia:~/julia$ git bisect bad
7c8acce9fb73c3edb71bdd509b8f265c95ae7484 is the first bad commit
commit 7c8acce9fb73c3edb71bdd509b8f265c95ae7484
Author: Oscar Blumberg <[email protected]>
Date:   Tue Jan 21 13:23:09 2014 +0000

    Generational behavior for the garbage collector.

:040000 040000 8d8978e45311c3bb71d407151161338998f14bac dfce27289d2c0f8d9a65c813637989172f243a2e M  base
:040000 040000 07ff18d2f74a10cca02bd35435279a34b16e068a 350aae4c1a60762612217b7684abbbe60231826c M  doc
:040000 040000 bb68f76fce25079e898566eb8281b972bbba25a2 1b9cea55469b48f2654945f58d6d150453eb41e5 M  src
:040000 040000 21073d3f6695f17f9fb2045d29403cedf62d4f27 7e693275b10cc9cb801df1fce7811d5027d756dc M  test
jameson@julia:~/julia$ git bisect log 
git bisect start
# good: [8938e3a32c68910ccfa84d5bb5f6c7850920a38a] Merge pull request #9758 from JuliaLang/tk/fix9753
git bisect good 8938e3a32c68910ccfa84d5bb5f6c7850920a38a
# bad: [6221ecf57fa6175e57816110c77e2e0d2253bd0e] Revert "codegen: insert unreachable blocks after throwing errors, rather than Br"
git bisect bad 6221ecf57fa6175e57816110c77e2e0d2253bd0e
# bad: [6221ecf57fa6175e57816110c77e2e0d2253bd0e] Revert "codegen: insert unreachable blocks after throwing errors, rather than Br"
git bisect bad 6221ecf57fa6175e57816110c77e2e0d2253bd0e
# good: [a2edd642979ce44932b1dadcd7575a5e3bd3f0f0] user defined transports
git bisect good a2edd642979ce44932b1dadcd7575a5e3bd3f0f0
# bad: [bf3882ad44be698cbbb4ab9cf9352b1b9d98278b] Improve test coverage for scale/scale!
git bisect bad bf3882ad44be698cbbb4ab9cf9352b1b9d98278b
# good: [4ff81458da07521d70ff3b568d3e2c8c3c240a2f] Merge pull request #9898 from eschnett/choose-correct-fma
git bisect good 4ff81458da07521d70ff3b568d3e2c8c3c240a2f
# bad: [cbdaa0c2dd198a49c7fca02df48042ab09cf49ab] basic markdown tests
git bisect bad cbdaa0c2dd198a49c7fca02df48042ab09cf49ab
# bad: [0bfe05df42fb8f38cf35c5b70e72e82f9c0e241c] Merge pull request #8699 from JuliaLang/ob/gengc
git bisect bad 0bfe05df42fb8f38cf35c5b70e72e82f9c0e241c
# good: [653af8b9548a18729d17361ff6ca102cede05a6c] Merge pull request #9905 from bicycle1885/push-associative
git bisect good 653af8b9548a18729d17361ff6ca102cede05a6c
# bad: [830a6dc33f47bf5186dc382b8a8b0c54b002e5b0] fix bug where a finalizer could be run twice if we end up in gc again after calling jl_gc_run_all_finalizers
git bisect bad 830a6dc33f47bf5186dc382b8a8b0c54b002e5b0
# bad: [7c8acce9fb73c3edb71bdd509b8f265c95ae7484] Generational behavior for the garbage collector.
git bisect bad 7c8acce9fb73c3edb71bdd509b8f265c95ae7484
# first bad commit: [7c8acce9fb73c3edb71bdd509b8f265c95ae7484] Generational behavior for the garbage collector.

jameson@julia:~/julia$ make -j
    CC src/gc.o
    LINK usr/lib/libjulia.so
    PERL base/version_git.jl.phony
    JULIA usr/lib/julia/sys0.o
exports.jl
base.jl
reflection.jl
build_h.jl
version_git.jl
c.jl
promotion.jl
tuple.jl
range.jl
expr.jl
error.jl
bool.jl
number.jl
int.jl
operators.jl
pointer.jl
rounding.jl
float.jl
julia: /home/jameson/julia/deps/llvm-3.5.0/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:308: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t, uint64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed.

(seems to be OK on llvm-svn)

[nalimilan]

That's weird, as on Fedora rawhide with LLVM 3.5.0 the build and tests pass: https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia-nightlies/fedora-rawhide-x86_64/julia-0.4.0-0.20150130.fc21/build.log.gz

Maybe again a distribution patch?

[vtjnash]

Perhaps related to the system malloc implementation too? Seemed to always fail on the same function however.

[JeffBezanson]

Could this be due to a very large mmap pushing some new code too far away from something it needs to reference?

[vtjnash]

probably. it should be fixed in llvm36 anyways though (keno tells me they do a better job at consolidating and ordering their mcjit allocations now, to match the assertions/assumptions later in code emission)

[vtjnash]

seems to be fixed now / not come up in a while