Julia: Julia 1.4 fails on startup (AMD Phenom on Linux)

[alea54]

uname -a
Linux odie 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cpuinfo.txt
errjulia-1.4.txt

[jdadavid]

Similar error here, on AMD Turion :

uname -a
Linux qube.jdad.org 5.5.9-desktop-1.mga7 #1 SMP Thu Mar 12 08:02:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

err-julia-1.4.0-turion.txt
cpuinfo-turion.txt

Attaching also versioninfo from (working) julia-1.3.1
julia-1.3-versioninfo-turion.txt

[ViralBShah]

Did you happen to try RC1 or RC2?

[benz0li]

Fails on startup (QEMU Virtual CPU):

$ julia
LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!

$ uname -a
Linux aa614eb95626 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 GNU/Linux

cpuinfo.txt

---

Related to https://github.com/llvm/llvm-project/commit/b7b353be6044051cc4fa8888dd3d86a2a1b56d8c?

[alea54]

@ViralBShah : Just tried. Both RC1 and RC2 start normally.

[fredrikekre]

Has to be the new llvm binaries then I guess? https://github.com/JuliaLang/julia/compare/v1.4.0-rc2...v1.4.0

[fabmazz]

It fails to start also on my pc (AMD Phenom II X6 1075T) on system running fedora 31.
Running julia produces the following stack trace:
julia_err.txt

$uname -a
Linux desktopsopra 5.5.8-200.fc31.x86_64 #1 SMP Thu Mar 5 21:28:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[staticfloat]

It appears your machines are complaining at a palignr instruction. You can see in that linked webpage that the instruction is marked as "SSSE3", and that its opcode starts with 66 0F 3A 0F.

Our typical processor support mantra so far has been "core2 or greater", but what that actually means hasn't been that well-defined; we often used only older instructions, but newer instructions keep getting used by various tools in our toolchains, and they often give significant speedups (As an example, GMP and MPFR, the libraries behind our BigInt capabilities, recently had a 2x performance difference when restricted to only older instructions).

It appears that what's happened here is that the LLVM rebuild for 1.4.0 was done with a newer GCC version, which ended up using SSSE3 instructions where it previously didn't, and while that still passes the "core2 or greater" check (and thus was passed by our CI), it looks like you need a Bobcat/Bulldozer or later AMD processor to have SSSE3 support.

[fabmazz]

In the end I compiled everything from scratch using the instructions on the julia repo.
I've uploaded the package I created to: https://github.com/fabmazz/julia/releases/tag/v1.4.0-amd10
If you share the same microarchitecture (amd k10), it should work also on your computer.

[jdadavid]

Dear Fabio, many thanks ! it works for my Turion II M640 !

Le 23/03/2020 à 23:50, Fabio Mazza a écrit :
>

In the end I compiled everything from scratch using the instructions
on the julia repo.
I've uploaded the package I created to:
https://github.com/fabmazz/julia/releases/tag/v1.4.0-amd10
If you share the same microarchitecture, it should work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-602898940,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2XLAXJMJSOBFHYMR52N3DRI7RR7ANCNFSM4LRFB5WQ.

[ViralBShah]

One of the things that this issue brings up is that we should probably formalize our informal min-CPU requirements. As @staticfloat says, we always assume something like core2 when we build all our binaries - and it sounds like some of these AMD systems are not compatible - since they don't have the newer instructions.

It may be that we have to drop older architectures and formalize what we require. I know it would be terrible for some users with systems like those in this issue - but perhaps we suggest they build from source. There are further ramifications beyond just Julia itself in the entire BinaryBuilder ecosystem where similar assumptions are perhaps being made.

[fabmazz]

I agree.
I think it should be made clear which CPU instructions Julia's official
binary requires in order to run properly, and how to check if one's CPU is
supported.
Providing other builds for older CPUs should be great, also.

Il Mar 24 Mar 2020, 15:54 Viral B. Shah [e-mail] ha
scritto:

One of the things that this issue brings up is that we should probably
formalize our informal min-CPU requirements. As @staticfloat
https://github.com/staticfloat says, we always assume something like
core2 when we build all our binaries - and it sounds like some of these
AMD systems are not compatible - since they don't have the newer
instructions.

It may be that we have to drop older architectures and formalize what we
require. I know it would be terrible for some users with systems like those
in this issue - but perhaps we suggest they build from source. There are
further ramifications beyond just Julia itself in the entire BinaryBuilder
ecosystem where similar assumptions are perhaps being made.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-603286381,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMONLPUABPVAWBD3W62BUDRJDCTLANCNFSM4LRFB5WQ
.

[alea54]

@fabmazz Thank you very much. Your binary did not work for me because your libc6 is too recent for my computer, but I recompiled with
MARCH=amdfam10
USE_BINARYBUILDER=0
in Make.user and it works.

[briochemc]

👍 Had the same issue when I updated to Julia v1.4 for running simulations on a HPC cluster that has some old AMD CPU (model: AMD Opteron(tm) Processor 6176).

It would be great if this could be solved so that noob users like me can use Julia v1.4 without trying to build from source with some flags that I don't understand to be honest (embarassed noob here 😅) I will personally be reverting to using Julia v1.3 because that's much easier for me. But it would be great to be able to not have to do that 😃

[alea54]

I agree with briochemc. K10 is not so old nor exotic. Forgetting these architectures would be very bad for Julia dissemination.

Meanwhile, you can use 1.4.0-rc2
https://sourceforge.net/projects/julia.mirror/files/v1.4.0-rc2/

[briochemc]

Meanwhile, you can use 1.4.0-rc2

I got that but I had 1.3.1 already installed, so I just reverted back to using it because that's the easiest in my case.

[yuyichao]

Our typical processor support mantra so far has been "core2 or greater", but what that actually means hasn't been that well-defined

It was pretty well defined (based on codegen) as sse2.

[pfarndt]

I have a 48 CPU machine with (according to /proc/cpuinfo includes sse2):

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm
3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm 
pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt 
lbrv svm_lock nrip_save pausefilter

bugs            : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2

but still julia-1.4.0 won't run. However, the above provided version 1.4.0-rc2 actually does run.

[KristofferC]

1.4.0-rc2 didn't use the same LLVM build.

[shkit]

I'm using a old AMD processor (Opteron 2374 HE) and encountered this problem.
I agreed that these old processors may be threw way, but I want to see these requirements in Release Notes or "this processor is not supported." message on Julia starts.

By the way, Linux binary failes to start, but FreeBSD binary works well.
I'm wondering differences.

[gsagoo]

AMD Athlon(tm) II X4 630 Processor using Manjaro Linux.
I tried to run Julia 1.4.0 and Julia 1.4.1 and encountered the error below, I had to downgrade and will now probably uninstall Julia unless this problem gets resolved.

A major issue like this should not go unfixed for over a month.

`Invalid instruction at 0x7f8e638869f8: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0x61, 0x05, 0x00, 0x00, 0x48, 0xc1, 0xe0

signal (4): Illegal instruction
in expression starting at none:0`

[StefanKarpinski]

@gsagoo: Demanding fixes and "threatening" to go away doesn't make anyone more inclined to do free work for you. If you really want this fixed, you are entirely welcome to submit a fix yourself.

[fabmazz]

That's right of course, nobody should expect problems to be solved
instantaneously by the authors, but since the problem resides in the LLVM
libraries bundled with the official binary (not the language itself, or
anything that can be fixed with a pull request, from my point of view), I
think the solution has to be implemented by the maintainers themselves.
Please correct me if I'm wrong.
I feel this is an important issue, especially with people that aren't very
good with technology, who see just a "crash" and would probably renounce
using Julia, thinking it's broken.

Il Dom 19 Apr 2020, 18:08 Stefan Karpinski [e-mail] ha
scritto:

Demanding fixes and "threatening" to go away doesn't make anyone more
inclined to do free work for you. If you really want this fixed, you are
entirely welcome to submit a fix yourself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-616171676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMONLPBJ6YVMZD3SWM2D7TRNMOY7ANCNFSM4LRFB5WQ
.

[StefanKarpinski]

Sure, it could be improved in several ways, but that doesn't justify people being ungrateful and demanding about it. Minimum requirements should be documented clearly, and if a processor isn't supported, it would be better to just print a message saying that. And while a maintainer needs to merge any changes to fix this, this project is open source, you're using it for free and if you want something fixed, you can do the work to fix it instead of demanding that people you don't pay a dime to do it for you. If you're going to ask for fixes, at least be polite.

[ViralBShah]

A place where folks in this thread can help is in documenting the minimum requirements and linking those prominently in various places.

[gsagoo]

@StefanKarpinski Whether someone fixes the issue or not is up to them, you're right I am not paying anyone to maintain it, its their choice, Its not a "threat" to yourself or anyone else whether I leave Julia, its my freedom of choice to leave, I certainly don't owe Julia any allegiance.
I am not demanding a fix, merely pointing out the problem and the facts.
As @fabmazz most people will just see a crash upon start up and just leave.

[StefanKarpinski]

This is only an issue for hardware that is over a decade old and which we do not officially support. A better error message and documenting that we don't support such old hardware would be good.

[ViralBShah]

@gsagoo Your point is absolutely right, and I am in full agreement that it isn't a great experience and people will be unhappy and leave. I think your comment was made in the right spirit, which your reply reinforces.

A major issue like this should not go unfixed for over a month.

It is only when I saw this line above, that I immediately felt uncomfortable. My first thought was to write back something snarky. After all, these are 10 year old architectures that are unsupported, and affects a very small number of users (hence not a major issue). But then I had to tell myself that saying all this wouldn't help, and I should stay focussed on trying to address the issue. I knew immediately that given the extremely small number of compiler contributors we have, a fix in the llvm/compiler domain was not a good idea immediately - although it will happen eventually. In the meanwhile, what's the best way we can warn users -and hence my subsequent reply about focussing on documentation and communication. That is something a lot more people can engage in and help with.

The reason I point this out is only in response to the follow-on conversation above. Broad sweeping statements like that which overstate the issue do not help the project, gets everyone discussing all sorts of other things, and make things look bad to those passing by.

[krcabrer]

I try to compile with some suggestions. Still fails.

My cpu is; model name : AMD Phenom(tm) II X4 955 Processor.

I'm using gcc verrsion gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0

I'm usiing GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

I use this Make.user file also:

MARCH=amdfam10
OPENBLAS_TARGET_ARCH=NEHALEM
USE_BINARYBUILDER=0
OPENBLAS_USE_THREAD=0

This is error that I got;

julia_compiling_errors.txt

It does not work either. What else can I do?

[PallHaraldsson]

Until this year I used a 10 year old (I believe Jeff still has such old) Intel-based laptop (with CPU arch from 2006 older than AMD Phenom II launched in 2008, with CPU arch from 2007), and I was grateful Julia worked great! [AMD Bulldozer-based CPUs from "late 2011", and seemingly my old laptop, should work on Julia 1.4.]

@fabmazz, The long-term-version Julia 1.x would still work, and while it's not too helpful in many cases to be limited to it, I would suggest using the still working Julia 1.3.x and also making it an additional official LTS [EDIT: no going to happen] version (since there's no actual promised length of support, I think ok to have two LTS concurrently, and eventually dropping the former LTS).

[ViralBShah]

1.3 is not going to be LTS.

[jdadavid]

Are you sure you have all required prerequisites ? I see :

/usr/bin/ld: no se puede encontrar -lgfortran
so may be you dont have gfortran (correctly) installed.

For the record, following Fabio Mazza's and alea54's recommendations, I
use the following Make.user :

MARCH=amdfam10
OPENBLAS_TARGET_ARCH=BARCELONA
USE_BINARYBUILDER=0
And after the "make", I do a "make binary-dist" to get a packaging in
similar tar than the distribution one, ready to untar in /usr/local.
Also, I use the "julia-1.4.1-full.tar.gz" version of the source.

For installed tools prerequisites, see :

https://github.com/JuliaLang/julia/blob/master/doc/build/build.md

On my platform (Turion II) it works, but the compilation time is
somewhat long (4-6h)

Good luck !

PS. For possible convenience, I uploaded my compilation and packaging 
result ("julia-1.4.1-linux64-amdfam10.tar.gz", 86Mo) at :
http://dl.free.fr/lyLTdNT5M
but it is best if you can achieve compilation and test execution on your
own platform !

Le 20/04/2020 à 14:05, Kenneth Cabrera a écrit :
>

I try to compile with some suggestions. Still fails.

My cpu is; model name : AMD Phenom(tm) II X4 955 Processor.

I'm using gcc verrsion gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0

I'm usiing GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

I use this Make.user file also:

MARCH=amdfam10
OPENBLAS_TARGET_ARCH=NEHALEM
USE_BINARYBUILDER=0
OPENBLAS_USE_THREAD=0

This is error that I got;

julia_compiling_errors.txt
https://github.com/JuliaLang/julia/files/4503311/julia_compiling_errors.txt

It does not work either. What else can I do?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-616509363,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2XLAT54I7DAZM3CDYEMQLRNQ3BRANCNFSM4LRFB5WQ.

[jdadavid]

IMHO, it should be sufficient to let a warning note in the download page
that  :

"due to LLVM 8.0.1 regression (it now defaults "core2" target to needing
SSSE3 instructions, while previous LLVM 6.0.1 didnt before), the 1.4
versions may fail on some old AMD architectures (AMDFAM10, eg PHENOM and
similar) - in that case you will have to recompile for  your platform
using the source."

or something similarly worded, in a footnote maybe ?

Le 19/04/2020 à 23:03, Stefan Karpinski a écrit :
>

This is only an issue for hardware that is over a decade old and which
we do not officially support. A better error message and documenting
that we don't support such old hardware would be good.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-616224723,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2XLAQJUB46YBUSMNNJOGDRNNRIZANCNFSM4LRFB5WQ.

[krcabrer]

Are you sure you have all required prerequisites ? I see :
/usr/bin/ld: no se puede encontrar -lgfortran
so may be you dont have gfortran (correctly) installed. For the record, following Fabio Mazza's and alea54's recommendations, I use the following Make.user :

What is the gfortran may I use?

[krcabrer]

It is very interesting that the nightly builds(1.5.0-DEV.650) works fine with my old AMD cpu.

Should I expect that in the future I can't use julia new versions anymore (should I stuck on 1.0.5 LTS version)?

Future versions won't work with old AMD cpu?

[ViralBShah]

The requirement for SSE3 as the minimum will hold and will be documented. If things work, that is great. But it is unclear what will break. In general, pushing the minimum requirements allows us to pick more aggressive optimizations by default in Julia as well as BinaryBuilder - and it is hard to predict how all that will play out.

[krcabrer]

It is sad that julia won't work with old cpu. I will like to use julia, but I have a very big limitation if julia will work only for new cpu. SMH.

[jdadavid]

Le 20/04/2020 à 15:59, Kenneth Cabrera a écrit :
>

What is the gfortran may I use?

I see in your first message that :

I'm using gcc verrsion gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0

I'm usiing GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

I use this Make.user file also:

MARCH=amdfam10
OPENBLAS_TARGET_ARCH=NEHALEM
USE_BINARYBUILDER=0
OPENBLAS_USE_THREAD=0

I am not using Ubuntu - I use mageia7, where I use gcc-gfortran 8.4.0.
So I can not really help you. Trivial advices could include :

• do a make clean (or make cleanall, or make distcleanall) to restart
  from scratch - or even delete "julia-1.4.1" dir, and re-extract it from
  source tar.

• change OPENBLAS_TARGET_ARCH to BARCELONA

• check that you have development headers / dev packages corresponding
  to needed tools

• etc...

I am sorry I cant help you better,

I wish you good luck,

JDAD

[jdadavid]

Le 20/04/2020 à 16:17, Viral B. Shah a écrit :
>

The requirement for SSE3 as the minimum will hold and will be
documented. If things work, that is great. But it is unclear what will
break.

Note that whence "core2" includes SSE3 and SSSE3, "amdfam10" includes
only SSE3, not SSSE3, which was the primary issue. May we could insist
on this  difference?

Or, from "SSE3 as the minimum will hold"  some people (like me) could
infer (wrongly?) that it should work on amdfam10.

Thank for the good work, and sorry of the inconvenience of using older
systems ...

[ViralBShah]

@staticfloat's message above does mention SSSE3. Thanks for pointing this out. We'll need to formalize this carefully.

[krcabrer]

I got an update of the issue. I install a clean and new ubuntu. I install ubuntu 20.04. And now all julia versions works fine, 1.3.1, 1.4.1, and the dev version 1.5 also. So, is it really an AMD phenom processor issue?

[fabmazz]

Where did you install Julia from? If you got it from the Ubuntu repo, than
it doesn't concern this, because it is built with a different toolchain.

This issue is about the official binary.

Il Mar 28 Apr 2020, 15:49 Kenneth Cabrera [e-mail] ha
scritto:

I got an update of the issue. I install a clean and new ubuntu. I install
ubuntu 20.04. And now all julia versions works fine, 1.3.1, 1.4.1, and the
dev version 1.5 also. So, is it really an AMD phenom processor issue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-620619906,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMONLMAJHRYIOPJ734WQ53RO3NHDANCNFSM4LRFB5WQ
.

[wildart]

Just tested Julia 1.4.1 from https://julialang.org/, and have the same problem.

Invalid instruction at 0x7f7590b449f8: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0x61, 0x05, 0x00, 0x00, 0x48, 0xc1, 0xe0

signal (4): Illegal instruction
in expression starting at none:0
_ZN4llvm13LexicalScopes23assignInstructionRangesERNS_15SmallVectorImplISt4pairIPKNS_12MachineInstrES5_EEERNS_8DenseMapIS5_PNS_12LexicalScopeENS_12DenseMapInfoIS5_EENS_6detail12DenseMapPairIS5_SB_EEEE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm13LexicalScopes10initializeERKNS_15MachineFunctionE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm18LiveDebugVariables20runOnMachineFunctionERNS_15MachineFunctionE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at /home/art/Applications/julia-1.4.1/bin/../lib/julia/libLLVM-8jl.so (unknown line)
operator() at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:356
addModule at /buildworker/worker/package_linux64/build/usr/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h:84 [inlined]
addModule at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:485
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:747 [inlined]
jl_finalize_function at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:755
getAddressForFunction at /buildworker/worker/package_linux64/build/src/codegen.cpp:1414
jl_generate_fptr at /buildworker/worker/package_linux64/build/src/codegen.cpp:1510
jl_compile_method_internal at /buildworker/worker/package_linux64/build/src/gf.c:1912
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2153 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2322
_deepcopy_array_t at ./deepcopy.jl:99
deepcopy_internal at ./deepcopy.jl:92 [inlined]
deepcopy at ./deepcopy.jl:26 [inlined]
resize_nthreads! at ./threads.jl:30
resize_nthreads! at ./threads.jl:26 [inlined]
__init__ at ./grisu/grisu.jl:27
jfptr___init___13966 at /home/art/Applications/julia-1.4.1/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2144 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2322
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1700 [inlined]
jl_module_run_initializer at /buildworker/worker/package_linux64/build/src/toplevel.c:74
_julia_init at /buildworker/worker/package_linux64/build/src/init.c:788
main at /buildworker/worker/package_linux64/build/ui/repl.c:211
__libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
_start at ./julia-1.4.1/bin/julia (unknown line)
Allocations: 2505 (Pool: 2495; Big: 10); GC: 0

cpuinfo:

vendor_id   : AuthenticAMD
cpu family  : 16
model       : 10
model name  : AMD Phenom(tm) II X6 1090T Processor
stepping    : 0
microcode   : 0x10000dc
cpu MHz     : 1207.459
cache size  : 512 KB
physical id : 0
siblings    : 6
core id     : 5
cpu cores   : 6
apicid      : 5
initial apicid  : 5
fpu     : yes
fpu_exception   : yes
cpuid level : 6
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
bogomips    : 6421.16
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

Ubuntu 19.10
Linux krug-pc 5.3.0-46-generic #38-Ubuntu SMP Fri Mar 27 17:37:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[krcabrer]

Where did you install Julia from? If you got it from the Ubuntu repo, than it doesn't concern this, because it is built with a different toolchain. This issue is about the official binary.

I always download Julia form the official site. Both for ubuntu 18.04, now for ubuntu 20.04.
In ubuntu 18.04 Julia 1.3.1 fails, but on ubuntu 20.04 not. And I did not change anything in the computer the same old AMD phenom II X4 955 black edition processor.

Il Mar 28 Apr 2020, 15:49 Kenneth Cabrera [e-mail] ha scritto:

…
I got an update of the issue. I install a clean and new ubuntu. I install ubuntu 20.04. And now all julia versions work fine, 1.3.1, 1.4.1, and the dev version 1.5 also. So, is it really an AMD phenom processor issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#35215 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMONLMAJHRYIOPJ734WQ53RO3NHDANCNFSM4LRFB5WQ .

[graidl]

I also experienced the error message "LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!" on startup of Julia 1.4.1 on some not so new but also not that old machine, which does not support CPU flag sse3.
However, I could finally solve the problem by simply specifying target x86_64 on startup, i.e. calling
"julia -C x86_64". Maybe just specifying the appropriate target cpu in this way resolves the problem also for others, without the need of recompiling Julia from the sources.

A question to the developers (sorry if too naive): Wouldn't it be possible to check at Julia's startup the CPU's capabilities e.g. via /proc/cpuinfo (at least under Linux) and to automatically choose the right target for LLVM?

[yuyichao]

Your issue is unrelated to this one. What is the CPU you are using?

[graidl]

Sorry, I found this issue when searching for "LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!", benzOli seemed to report the same problem in this issue. CPU is a QEMU Virtual CPU, see attachment for details.
cpuinfo.txt

[yuyichao]

OK, it's a virtualized CPU, similar to the LLVM issue linked in https://github.com/JuliaLang/julia/issues/35215#issuecomment-602220755 and that's unrelated to the issue in the original post.

It indeed seems to be caused by the LLVM change of the 64bit feature bit. I was just curious what kind of CPU triggers this. It seems that this is triggering the LLVM feature based CPU guessing logic which is neither accurate or generic. (accurate or generic is basically the two cases where LLVM is handling this correctly).

The fix should be the same as the LLVM one, basically,

diff --git a/src/processor_x86.cpp b/src/processor_x86.cpp
index d433956bd8..c3bde2cb84 100644
--- a/src/processor_x86.cpp
+++ b/src/processor_x86.cpp
@@ -833,6 +833,9 @@ get_llvm_target_noext(const TargetData<feature_sz> &data)
     features.push_back("+sse2");
     features.push_back("+mmx");
     features.push_back("+fxsr");
+#ifdef _CPU_X86_64_
+    features.push_back("+64bit");
+#endif
     return std::make_pair(std::move(name), std::move(features));
 }

[graidl]

I can confirm that the above fixes my problem (unrelated to the issue in the original post). Thanks!

[siroccal]

I have an AMD Phenom II X6 CPU and I get the same error. Here is a download link to the latest binary version that still works for me: https://julialang-s3.julialang.org/bin/linux/x64/1.4/julia-1.4.0-rc2-linux-x86_64.tar.gz.

[jtappin]

Tried building from official sources (1.4.1) and still get this error (both before & after @yuyichao 's patch) when julia is invoked during the build.
````
Invalid instruction at 0x7fba1ca58ad0: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0xae, 0x04, 0x00, 0x00, 0x48, 0xc1, 0xe0

signal (4): Illegal instruction
in expression starting at sysimg.jl:3
_ZN4llvm13LexicalScopes23assignInstructionRangesERNS_15SmallVectorImplISt4pairIPKNS_12MachineInstrES5_EEERNS_8DenseMapIS5_PNS_12LexicalScopeENS_12DenseMapInfoIS5_EENS_6detail12DenseMapPairIS5_SB_EEEE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN4llvm13LexicalScopes10initializeERKNS_15MachineFunctionE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN12_GLOBAL__N_115LiveDebugValues20runOnMachineFunctionERN4llvm15MachineFunctionE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at /data/software/julia-1.4.1/usr/bin/../lib/libLLVM-8jl.so (unknown line)
operator() at /data/software/julia-1.4.1/src/jitlayers.cpp:356
addModule at /data/software/julia-1.4.1/usr/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h:84 [inlined]
addModule at /data/software/julia-1.4.1/src/jitlayers.cpp:485
jl_add_to_ee at /data/software/julia-1.4.1/src/jitlayers.cpp:747 [inlined]
jl_finalize_function at /data/software/julia-1.4.1/src/jitlayers.cpp:755
getAddressForFunction at /data/software/julia-1.4.1/src/codegen.cpp:1414
jl_generate_fptr at /data/software/julia-1.4.1/src/codegen.cpp:1510
jl_compile_method_internal at /data/software/julia-1.4.1/src/gf.c:1912
_jl_invoke at /data/software/julia-1.4.1/src/gf.c:2153 [inlined]
jl_apply_generic at /data/software/julia-1.4.1/src/gf.c:2322
jl_apply at /data/software/julia-1.4.1/src/julia.h:1700 [inlined]
do_call at /data/software/julia-1.4.1/src/interpreter.c:369
eval_value at /data/software/julia-1.4.1/src/interpreter.c:458
eval_stmt_value at /data/software/julia-1.4.1/src/interpreter.c:409 [inlined]
eval_body at /data/software/julia-1.4.1/src/interpreter.c:799
jl_interpret_toplevel_thunk at /data/software/julia-1.4.1/src/interpreter.c:911
jl_toplevel_eval_flex at /data/software/julia-1.4.1/src/toplevel.c:814
jl_parse_eval_all at /data/software/julia-1.4.1/src/ast.c:872
jl_load at /data/software/julia-1.4.1/src/toplevel.c:872
exec_program at /data/software/julia-1.4.1/ui/repl.c:35
true_main at /data/software/julia-1.4.1/ui/repl.c:108
main at /data/software/julia-1.4.1/ui/repl.c:217
__libc_start_main at /usr/lib/libc.so.6 (unknown line)
_start at /data/software/julia-1.4.1/usr/bin/julia (unknown line)
Allocations: 1 (Pool: 1; Big: 0); GC: 0
/bin/sh: line 1: 60418 Illegal instruction (core dumped) JULIA_BINDIR=/data/software/julia-1.4.1/usr/bin /data/software/julia-1.4.1/usr/bin/julia -g1 -O0 -C "native" --output-ji /data/software/julia-1.4.1/usr/lib/julia/sys.ji.tmp --startup-file=no --warn-overwrite=yes --sysimage /data/software/julia-1.4.1/usr/lib/julia/corecompiler.ji sysimg.jl
Running Manjaro linux, cpu info
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 10
model name : AMD Phenom(tm) II X6 1055T Processor
stepping : 0
microcode : 0x10000dc
cpu MHz : 803.551
cache size : 512 KB
physical id : 0
siblings : 6
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
bogomips : 5627.36
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

````

[giordano]

@jtappin I believe you need to build also LLVM from source, so you have to add

USE_BINARYBUILDER=0

to the file Make.user in the top-level directory, creare it if it doesn't exist. See https://github.com/JuliaLang/julia/blob/f705e6026cb3913de7dbb3f7992bd96031428d84/doc/build/build.md#building-julia

[jtappin]

Thanks @giordano that produces a working binary.
(Bit of a palaver though).

[ViralBShah]

This should be addressed as part of https://github.com/JuliaLang/julia/issues/34570

[yuyichao]

@alea54 @jdadavid does the 1.1.1 generic binary works for you?

Also, does big"1.0" + 5.0 works with the 1.1.1 binary?

[jdadavid]

Le 05/06/2020 à 06:46, Yichao Yu a écrit :
>

@alea54 https://github.com/alea54 @jdadavid
https://github.com/jdadavid does the 1.1.1 generic binary
https://julialang-s3.julialang.org/bin/linux/x64/1.1/julia-1.1.1-linux-x86_64.tar.gz
works for you?

Yes

Also, does |big"1.0" + 5.0| works with the 1.1.1 binary?

Yes

regards,

JDAD

[yuyichao]

Thx. so there appears to be no valid reason to raise the hardware requirement AFAICT.

[xianwenchen]

To build a binary that fits all x86_64 CPUs, one specifies MARCH=x86-64. Is there an equivalent setting for OPENBLAS_TARGET_ARCH?

To build a binary that is optimized for the local CPU, one specifies MARCH=native. Is there an equivalent setting for OPENBLAS_TARGET_ARCH?

[yuyichao]

You shouldn't need to do anything since openblas can detect CPU uarch at runtime. Also it's unrelated to this issue.

[xianwenchen]

Thank you. The question regarding openblas is related to this issue, when one tries to produce a Julia binary that will run on all x86-64 CPUs.

[yuyichao]

No, this issue is about the generic binary you download doesn't work on all x64 CPUs. The flag you use to compile openblas isn't the issue that causes it. If you have questions about how to compile julia yourself, please post the question on http://discourse.julialang.org/.

[xianwenchen]

What's the verdict now regarding the solution to this issue? There was an earlier suggestion to specifically state what CPUs are not supported. Is that going to be the outcome? If yes, then it is relevant for this issue, that someone produces a Julia binary that will fit all x86-64 CPUs, including the old ones that the official binary does not support.

[staticfloat]

I have been running my own experiments which verify Yichao's findings; namely that newer GCC versions get very good performance with even the restricted x86-64 instruction sets on GMP and MPFR, and so there is one less reason for us to restrict Julia itself to require SSSE3 instructions.

I've been trying to get us to come to a decision on the triage slack channel, but so far the right people have not been online to discuss it yet. But I think most likely what will happen is that Julia 1.6 will roll back the requirement for Julia itself, especially as we have new support coming into BB (it's not built yet, but should be ready somewhere around the 1.6 release timeframe) for building microarchitecture-specific tarballs for packages that really need it. This will allow us to get the best of both worlds for our binary dependencies as well. I am not 100% certain this will happen, as some other devs may have usecases that preclude this, but I think it likely this will happen.

I do not think this issue will be solved for Julia 1.4 or 1.5, as it's too late in the release cycle to go and rebuild all the dependencies. For the time being, to get a Julia that runs on these older machines, the best solution is still to build from source with USE_BIANRYBUILDER=0. Unfortunately, most binary packages will not work due to the same issue, and there's no easy fix for that.

[yuyichao]

as it's too late in the release cycle to go and rebuild all the dependencies.

Well, just build the generic binary with USE_BIANRYBUILDER=0.

Unfortunately, most binary packages will not work due to the same issue, and there's no easy fix for that.

Rebuilding everything without the march set is still a solution, and I assume there's a way to reset the database to trigger that. It probably won't be fast but it can be done and it won't block any julia release since those will not use the BB binaries.

[yuyichao]

And really it won't even be everything. It's everything after https://github.com/JuliaPackaging/Yggdrasil/pull/358 is deployed. It should take no longer than 5 months o rebuild on a super low capacity and probably much faster. And the sooner the rebuild start the shorter it'll take.

[yuyichao]

There was an earlier suggestion to specifically state what CPUs are not supported. Is that going to be the outcome?

No, that's not acceptable.

If yes, then it is relevant for this issue, that someone produces a Julia binary that will fit all x86-64 CPUs, including the old ones that the official binary does not support.

And no even if that's the case, the build instruction when you want to compile julia on your own is still a different issue. It'll indeed get more important if the requirement changes but discussing it does not help reaching a decision or solution on this issue. It very much still deserve an answer which is why I suggested you to open a thread on discourse and I (and many others) can answer all the questions you may have about what target to use.

[stochastic-thread]

I have a 6 year old dell r710 for my homelab and I can't use Julia because of this.

I am sad. Gotta really recompile the binary because of some LLVM nonsense? That sucks bigly

[PallHaraldsson]

@stochastic-thread there's a way for you to use Julia, even latest versions(s): 32-bit Julia has tier 1 support on Windows (and tier 2 on Linux), and should work with even very old CPUs.

Assuming you really need, or just want a 64-bit version, I see a comment linking to the latest, I think, Julia version (currently) available for older CPUs (up to 12 year old AMDs): https://github.com/JuliaLang/julia/issues/35215#issuecomment-631662990

I'm not sure what https://github.com/JuliaLang/julia/pull/36502 changes, but it at least seems people are working on getting more CPUs to work. If Julia 1.6 (nightly, look at the download page) works for you then great, and the relevant change might get backported to 1.5.1: https://github.com/JuliaLang/julia/pull/36899

https://github.com/JuliaLang/julia/issues/35215#issuecomment-616552279

[yuyichao]

No https://github.com/JuliaLang/julia/pull/36502 has nothing to do with this issue. Julia has always been working on these old CPU's. This is purely a build problem and requires absolutely no change in julia itself.

[jdadavid]

Dear stochastic-thread,

If you are using Linux on you Dell, you could use the version I did
compile for my own use

( julia-1.5.0-linux64-barcelona.tar.gz )

that I just uploaded to :

http://dl.free.fr/tO9fUNCAj

(should stay up one month after last up/download)

Good luck  and best wishes,

JDAD

Le 07/08/2020 à 09:43, stochastic-thread a écrit :
>

I have a 6 year old dell r710 for my homelab and I can't use Julia
because of this.

I am sad. Gotta really recompile the binary because of some LLVM
nonsense? That sucks bigly

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-670379676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2XLAW6XZ2JJPT7EU2RRODR7OWBNANCNFSM4LRFB5WQ.

[stochastic-thread]

Thank you, appreciate it!

[staticfloat]

We recently rebuilt all the GCC shards for BinaryBuilder, changing the default microarchitecture back to x86-64. This, paired with the already-merged but yet-unused capability for BinaryBuilder to generate microarchitecture-specific tarballs, will give us the best of both worlds; fast binaries when possible, but maximally compatible when we must be.

The dependencies of Julia itself (such as LLVM, GMP, MPFR, etc...) must be rebuilt with these new BB GCC shards, I will collect here the list of things that need to be rebuilt:

Julia's binary dependencies that need to be rebuilt:

• [x] OpenBLAS
• [ ] LibCURL
• [x] GMP
• [x] LibGit2
• [ ] LibSSH2
• [ ] LibUV
• [ ] LLVM
• [x] MbedTLS
• [x] MPFR
• [x] OpenLibm
• [x] p7zip
• [x] SuiteSparse
• [x] Zlib_jll
• [X] LibOSXUnwind (not important; this issue doesn't affect any macs we support)

Many of these will be naturally rebuilt over the course of us working on the 1.6 release, but rebuilding the current versions with the new BB shards and backporting those new binaries onto the 1.5 release is definitely possible. If anyone is interested in doing that work, I'll be happy to coach them through it, it's quite simple, just a little rote and time-consuming.

[ViralBShah]

People are now reporting that Julia 1.5 does work on these older CPUs. Perhaps it just means that it doesn't segfault on startup.

[giordano]

People are now reporting that Julia 1.5 does work on these older CPUs. Perhaps it just means that it doesn't segfault on startup.

That was from an ArchLinux user who installed the julia package from official ArchLinux repositories, which uses system libraries, not those provided by BinaryBuilder

[jtappin]

People are now reporting that Julia 1.5 does work on these older CPUs. Perhaps it just means that it doesn't segfault on startup.

That was from an ArchLinux user who installed the julia package from official ArchLinux repositories, which uses system libraries, not those provided by BinaryBuilder

Also working on Manjaro (which I think uses the same package as Arch for julia).

[jdadavid]

Seeing people saying "it works now", I did a new test on my AMD Turion M640.

Stock julia effectively starts OK, but then fails when doing a version
info (or a Pkg update)...

[davidj@qube tmp]$ ./julia-1.5.1/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.1 (2020-08-25)
 _/ |__'_|_|_|__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> versioninfo()
Invalid instruction at 0x7fd4d6697c07: 0x66, 0x0f, 0x3a, 0x0f, 0xc0,
0x08, 0x0f, 0x29, 0x84, 0x24, 0xb0, 0x03, 0x00, 0x00, 0xe8

signal (4): Illegal instruction
in expression starting at REPL[1]:1
_ZN4llvm17SLPVectorizerPass18tryToVectorizeListENS_8ArrayRefIPNS_5ValueEEERNS_13slpvectorizer7BoUpSLPEib
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm17SLPVectorizerPass18tryToVectorizePairEPNS_5ValueES2_RNS_13slpvectorizer7BoUpSLPE
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm17SLPVectorizerPass14tryToVectorizeEPNS_11InstructionERNS_13slpvectorizer7BoUpSLPE
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZL40tryToVectorizeHorReductionOrInstOperandsPN4llvm7PHINodeEPNS_11InstructionEPNS_10BasicBlockERNS_13slpvectorizer7BoUpSLPEPNS_19TargetTransformInfoENS_12function_refIFbS3_S8_EEE.constprop.1422
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm17SLPVectorizerPass24vectorizeRootInstructionEPNS_7PHINodeEPNS_5ValueEPNS_10BasicBlockERNS_13slpvectorizer7BoUpS
...

jl_f__apply_latest at
/buildworker/worker/package_linux64/build/src/builtins.c:705

invokelatest#1 at ./essentials.jl:710 [inlined]

invokelatest at ./essentials.jl:709 [inlined]
run_main_repl at ./client.jl:383
exec_options at ./client.jl:313
_start at ./client.jl:506
jfptr__start_51675 at /tmp/julia-1.5.1/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214
[inlined]
jl_apply_generic at
/buildworker/worker/package_linux64/build/src/gf.c:2398
jl_apply at
/buildworker/worker/package_linux64/build/ui/../src/julia.h:1690 [inlined]
true_main at /buildworker/worker/package_linux64/build/ui/repl.c:106
main at /buildworker/worker/package_linux64/build/ui/repl.c:227
__libc_start_main at /lib64/libc.so.6 (unknown line)
_start at ./julia-1.5.1/bin/julia (unknown line)
Allocations: 5329383 (Pool: 5327226; Big: 2157); GC: 6
Illegal instruction (core dumped)
[davidj@qube tmp]$

[davidj@qube tmp]$ ./julia-1.5.1/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.1 (2020-08-25)
 _/ |__'_|_|_|__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.5) pkg> up
   Updating registry at ~/.julia/registries/General

##################################################################

100.0%
Invalid instruction at 0x7fe20b68f2f1: 0x66, 0x0f, 0x3a, 0x0f, 0xc0,
0x08, 0x0f, 0x11, 0x40, 0xf0, 0x66, 0x0f, 0x6f, 0xc1, 0x4d

signal (4): Illegal instruction
in expression starting at none:0
_ZNSt6vectorIPN4llvm17MachineBasicBlockESaIS2_EE15_M_range_insertISt16reverse_iteratorIN9__gnu_cxx17__normal_iteratorIPS2_S4_EEEEEvSA_T_SC_St20forward_iterator_tag
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm13LiveVariables23MarkVirtRegAliveInBlockERNS0_7VarInfoEPNS_17MachineBasicBlockES4_RSt6vectorIS4_SaIS4_EE
at /tmp/julia-1.5.1/bin/../lib/julia/libLLVM-9jl.so (unknown line)
...

invokelatest#1 at ./essentials.jl:710 [inlined]

invokelatest at ./essentials.jl:709 [inlined]
run_interface at
/buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/LineEdit.jl:2355
jfptr_run_interface_70362 at /tmp/julia-1.5.1/lib/julia/sys.so
(unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214
[inlined]
jl_apply_generic at
/buildworker/worker/package_linux64/build/src/gf.c:2398
run_frontend at
/buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:1144

38 at ./task.jl:356

jfptr_YY.38_71508 at /tmp/julia-1.5.1/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214
[inlined]
jl_apply_generic at
/buildworker/worker/package_linux64/build/src/gf.c:2398
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1690
[inlined]
start_task at /buildworker/worker/package_linux64/build/src/task.c:707
unknown function (ip: (nil))
Allocations: 4400767 (Pool: 4398553; Big: 2214); GC: 7
Illegal instruction (core dumped)
[davidj@qube tmp]$

So I will keep using my "barcelona-arch-compiled" version ...

regards,

jdad

NB. The working recompiled binary :

[davidj@qube ~]$ julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.1 (2020-08-25)
 _/ |__'_|_|_|__'_|  |
|__/                   |

julia> versioninfo()
Julia Version 1.5.1
Commit 697e782ab8* (2020-08-25 20:08 UTC)
Platform Info:
  OS: Linux (x86_64-mageia-linux-gnu)
  CPU: AMD Turion(tm) II Ultra Dual-Core Mobile M640
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, amdfam10)
Environment:
  JULIA_EDITOR = vim

julia>

PPS.

Le 09/09/2020 à 18:21, James Tappin a écrit :
>

    People are now reporting that Julia 1.5 does work on these
    older CPUs. Perhaps it just means that it doesn't segfault on
    startup.

That was from an ArchLinux user who installed the |julia|
<https://www.archlinux.org/packages/community/x86_64/julia/>
package from official ArchLinux repositories, which uses system
libraries
<https://github.com/archlinux/svntogit-community/blob/61468217f3f96bf9565f91d2c585ef0675d1f490/trunk/PKGBUILD#L43-L66>,
not those provided by BinaryBuilder

Also working on Manjaro (which I think uses the same package as Arch
for julia).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35215#issuecomment-689670697,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2XLAWBLDRKJSUV5U53W2LSE6TR3ANCNFSM4LRFB5WQ.

[giordano]

As I said above, people not experiencing the problem are using a Julia version in Arch repositories that doesn't use libraries built with BinaryBuilder, which however can lead to other problems at a different point

[ViralBShah]

The good news is that the compiler have been upgraded but they have to work their way through everything.