llvmlite v0.40.0

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows no discrepancy with the stated requirements in the meta.yaml.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/4865207023, please use this URL for debugging.}

Closes #66

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

Seeing the following sorts of errors in PyPy builds:

======================================================================
ERROR: test_per_diamond_1 (llvmlite.tests.test_refprune.TestDiamond)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/site-packages/llvmlite/tests/test_refprune.py", line 265, in test_per_diamond_1
    mod, stats = self.check(self.per_diamond_1)
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/site-packages/llvmlite/tests/test_refprune.py", line 177, in check
    before = llvm.dump_refprune_stats()
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/site-packages/llvmlite/binding/passmanagers.py", line 54, in dump_refprune_stats
    ffi.lib.LLVMPY_DumpRefPruneStats(byref(stats), do_print)
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/site-packages/llvmlite/binding/ffi.py", line 152, in __call__
    return self._cfn(*args, **kwargs)
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/_ctypes/function.py", line 365, in __call__
    funcptr = self._getfuncptr(argtypes, self._restype_, thisarg, variadic_args=variadic_args)
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/_ctypes/function.py", line 435, in _getfuncptr
    ptr = self._getfuncptr_fromaddress(argtypes, restype, variadic_args=variadic_args)
  File "/home/conda/feedstock_root/build_artifacts/llvmlite_1683058932597/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/pypy3.9/_ctypes/function.py", line 425, in _getfuncptr_fromaddress
    return _ffi.FuncPtr.fromaddr(address, '', ffiargs, ffires, self._flags_,
SystemError: not supported by libffi

Seeing the following sorts of errors in Windows builds:

LINK : fatal error LNK1181: cannot open input file 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\DIA SDK\lib\amd64\diaguids.lib' [%SRC_DIR%\ffi\build\llvmlite.vcxproj]

[jakirkham]

cc @stuartarchibald (for awareness)

[stuartarchibald]

@jakirkham I think the recipe is using LLVM 11. IIRC, whilst you can still build llvmlite with 11, Numba needs LLVM 14. I also seem to recall seeing the issue above (from PyPy on windows) elsewhere, the cause was using an unexpected LLVM build, I'm not sure if that's also the case here.

[jakirkham]

@conda-forge-admin, please re-render

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/llvmlite-feedstock/actions/runs/4874281264.

[jakirkham]

I think the recipe is using LLVM 11. IIRC, whilst you can still build llvmlite with 11, Numba needs LLVM 14.

Ah thanks Stuart! Missed this. Have pushed a change to move to 14.

I also seem to recall seeing the issue above (from PyPy on windows) elsewhere, the cause was using an unexpected LLVM build, I'm not sure if that's also the case here.

The Windows issues seem to happen on CPython & PyPy. Looks like the same linking issue AFAICT. Though maybe it is worth waiting for LLVM 14 builds to see if this just due to an old library on VMs that have largely moved on

The other PyPy issues were on Linux (x86_64, aarch64 & ppc64le). Seems to be the same issue on all of these. Not sure if you have thoughts there

[stuartarchibald]

I think the recipe is using LLVM 11. IIRC, whilst you can still build llvmlite with 11, Numba needs LLVM 14.

Ah thanks Stuart! Missed this. Have pushed a change to move to 14.

No problem, thanks for doing that.

I also seem to recall seeing the issue above (from PyPy on windows) elsewhere, the cause was using an unexpected LLVM build, I'm not sure if that's also the case here.

The Windows issues seem to happen on CPython & PyPy. Looks like the same linking issue AFAICT. Though maybe it is worth waiting for LLVM 14 builds to see if this just due to an old library on VMs that have largely moved on

Unfortunately, it seems like this error is still present when using LLVM 14.

The other PyPy issues were on Linux (x86_64, aarch64 & ppc64le). Seems to be the same issue on all of these. Not sure if you have thoughts there

All the failing tests are those which rely on a custom LLVM compiler pass that is compiled and shipped from llvmlite's source. The error suggests _ffi.FuncPtr.fromaddr is not supported by libffi but I don't think llvmlite has changed the way this pass is loaded/accessed since llvmlite 0.39 which appears to have built successfully on PyPy. I wonder if the problem is maybe something link resolution related instead and the error just ends up at that point in FFI loading.

[jakirkham]

Are any of these issues related to missing patches to LLVM ( conda-forge/llvmdev-feedstock#192 ) ( conda-forge/llvmdev-feedstock#209 )?

[jakirkham]

cc @mattip (in case the FFI PyPy errors seem familiar)

[mattip]

PyPy refactored the way it uses variadac arguments in the release of about a year ago, when we added support for M1 and its calling convention. Now functions with poorly specified arguments can fall afoul of using variadac arguments where not expected. There is some discussion of the problem in this issue. Is there an easy way to reduce this to a smaller reproducer?

[mattip]

PyPy refactored the way it uses variadac arguments in the release of about a year ago, when we added support for M1 and its calling convention. Now functions with poorly specified arguments can fall afoul of using variadac arguments where not expected. There is some discussion of the problem in this issue. Is there an easy way to reduce this to a smaller reproducer?

[jakirkham]

There's a number of tests referred to in the PyPy build logs that run into some form of this error. Here's a list of the unit test functions:

test_fanout_1
test_fanout_2
test_fanout_3
test_fanout_3_limited
test_fanout_raise_1
test_fanout_raise_2
test_fanout_raise_3
test_fanout_raise_4
test_fanout_raise_5
test_per_bb_1
test_per_bb_2
test_per_bb_3
test_per_bb_4
test_per_diamond_1
test_per_diamond_2
test_per_diamond_3
test_per_diamond_4
test_per_diamond_5

Am a little unsure how we get from one of these tests to a simpler reproducer. Maybe someone else can advise? Alternatively could try running one of these tests to see what happens

Sorry not to be more helpful here

[maxnoe]

Would it be possible to already release the packages for which the build succeeds? Or does that create too much overhead?

We are very interested in getting numba on python 3.11 using conda-forge, but are fine with cpython on linux x86 and macos

[maxnoe]

Ah, I notice there aren't any python 3.11 builds (yet?) in this PR

[jakirkham]

Would it be possible to already release the packages for which the build succeeds? Or does that create too much overhead?

Given there are a few upstream issues in the LLVM packages being worked on ( #69 (comment) ), it is probably better to wait on those

Ah, I notice there aren't any python 3.11 builds (yet?) in this PR

Depends on PR ( #66 )

Edit: Merged those changes into this PR

[stuartarchibald]

@jakirkham the failure on PyPy is tracked by numba/llvmlite#944 and hopefully fixed by numba/llvmlite#945, which will be in a llvmlite 0.40.1 release. The hint for working out what was wrong was from @mattip mentioning variadic arg handling changes here #69 (comment) and that lead to us finding a location where they were potentially being used where something concrete was possible. Thanks for the help with this!

[jakirkham]

Thanks Stuart! 🙏

Would it make sense to apply PR ( numba/llvmlite#945 ) as a patch here? Or is the hot-fix release coming out soon?

[igozali]

Are any of these issues related to missing patches to LLVM ( conda-forge/llvmdev-feedstock#192 ) ( conda-forge/llvmdev-feedstock#209 )?

To clarify, does that mean the build issues in this PR isn't related to the quoted llvmdev-feedstock issues?

[jakirkham]

Both of those PRs are relevant for Numba specifically

What was less clear (hence the question) was whether they contributed to the CI failures in this PR

[jakirkham]

Have gone ahead and applied a patch for the PyPy issue

Also there have been some rebuilds of LLVM recently, which may have fixed some issues on Windows. Though the PRs noted above are still pending

Will see how things look in fresh builds

[jakirkham]

So far this is looking good. Going to go ahead and add automerge to get these out (once CI is done)

As LLVM is linked to dynamically, those fixes will get picked up whenever a new build of that package is made

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[stuartarchibald]

Thanks Stuart! pray

Would it make sense to apply PR ( numba/llvmlite#945 ) as a patch here? Or is the hot-fix release coming out soon?

@jakirkham apologies for the slow reply. llvmlite 0.40.1 isn't finalised and hasn't been through RC, so the above is probably the quickest way to potentially fix this issue for PyPy users. Looks like the later LLVM builds have fixed the issues on Windows too.

[jakirkham]

No worries. Thanks for getting back to me 🙏

Sounds good. Looked at the project board and got the sense there was more work to do there

Yeah happy to carry a patch for a little bit until a new release appears

Yep think the issue was LLVM packages were built with older Windows toolchains. So any new build would have fixed it (and there were several builds recently for various changes)

Still would be good to have LLVM rebuilt with these patches ( conda-forge/llvmdev-feedstock#192 ), but there isn't anything else needed here to use those packages (once built)