LLVM ERROR: Symbol not found: __sync_fetch_and_add_4 running tests on armv7l (armel)

• [No ] I have tried using the latest released version of Numba (0.52 tested, not 0.54).
• [Yes] I have included a self contained code sample to reproduce the problem. python3 -m numba.runtests --log -lv

numba 0.52 is crashing on armv7l (armel). The error message is

LLVM ERROR: Symbol not found: __sync_fetch_and_add_4

It 's the same error message as reported in #3052 , but that instance was supposed to have been fixed already.

This is on a debian unstable armel build with python3-numba 0.52.0-4, llvm-9 1:9.0.1-20.

A detailed test log reports

experimental_armel-dchroot$ python3 -m numba.runtests --log -lv
DEBUG:numba.core.byteflow:bytecode dump:
>          0	NOP(arg=None, lineno=38)
           2	LOAD_FAST(arg=0, lineno=38)
           4	LOAD_FAST(arg=1, lineno=38)
           6	BINARY_ADD(arg=None, lineno=38)
           8	RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:pending: deque([State(pc_initial=0 nstack_initial=0)])
DEBUG:numba.core.byteflow:stack: []
DEBUG:numba.core.byteflow:dispatch pc=0, inst=NOP(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=2, inst=LOAD_FAST(arg=0, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=4, inst=LOAD_FAST(arg=1, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0']
DEBUG:numba.core.byteflow:dispatch pc=6, inst=BINARY_ADD(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0', '$b4.1']
DEBUG:numba.core.byteflow:dispatch pc=8, inst=RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$6binary_add.2']
DEBUG:numba.core.byteflow:end state. edges=[]
DEBUG:numba.core.byteflow:-------------------------Prune PHIs-------------------------
DEBUG:numba.core.byteflow:Used_phis: defaultdict(<class 'set'>, {State(pc_initial=0 nstack_initial=0): set()})
DEBUG:numba.core.byteflow:defmap: {}
DEBUG:numba.core.byteflow:phismap: defaultdict(<class 'set'>, {})
DEBUG:numba.core.byteflow:changing phismap: defaultdict(<class 'set'>, {})
DEBUG:numba.core.byteflow:keep phismap: {}
DEBUG:numba.core.byteflow:new_out: defaultdict(<class 'dict'>, {})
DEBUG:numba.core.byteflow:----------------------DONE Prune PHIs-----------------------
DEBUG:numba.core.byteflow:block_infos State(pc_initial=0 nstack_initial=0):
AdaptBlockInfo(insts=((0, {}), (2, {'res': '$a2.0'}), (4, {'res': '$b4.1'}), (6, {'lhs': '$a2.0', 'rhs': '$b4.1', 'res': '$6binary_add.2'}), (8, {'retval': '$6binary_add.2', 'castval': '$8return_value.3'})), outgoing_phis={}, blockstack=(), active_try_block=None, outgoing_edgepushed={})
DEBUG:numba.core.interpreter:label 0:
    a = arg(0, name=a)                       ['a']
    b = arg(1, name=b)                       ['b']
    $6binary_add.2 = a + b                   ['$6binary_add.2', 'a', 'b']
    $8return_value.3 = cast(value=$6binary_add.2) ['$6binary_add.2', '$8return_value.3']
    return $8return_value.3                  ['$8return_value.3']

DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:Running <numba.core.ssa._GatherDefsHandler object at 0xae297c70>
DEBUG:numba.core.ssa:on stmt: a = arg(0, name=a)
DEBUG:numba.core.ssa:on stmt: b = arg(1, name=b)
DEBUG:numba.core.ssa:on stmt: $6binary_add.2 = a + b
DEBUG:numba.core.ssa:on stmt: $8return_value.3 = cast(value=$6binary_add.2)
DEBUG:numba.core.ssa:on stmt: return $8return_value.3
DEBUG:numba.core.ssa:defs defaultdict(<class 'list'>,
            {'$6binary_add.2': [<numba.core.ir.Assign object at 0xae29d0a0>],
             '$8return_value.3': [<numba.core.ir.Assign object at 0xae29d118>],
             'a': [<numba.core.ir.Assign object at 0xae29d298>],
             'b': [<numba.core.ir.Assign object at 0xae29d6d0>]})
DEBUG:numba.core.ssa:SSA violators set()
LLVM ERROR: Symbol not found: __sync_fetch_and_add_4

So the error seems to be happening in numba.core.ssa.

[drew-parsons]

llvmlite 0.37 is now packaged for debian. The next delay is support for Python 3.10, #7562

[gmarkall]

I just tried the SD card in a Raspberry Pi 3 (as it’s ARMv8, a Cortex A53 IIUC) and didn’t replicate the issue in that either (though I did also still see the machine listed as armv7l).