search

conda-forge / openblas-feedstock

A conda-smithy repository for openblas.
BSD 3-Clause "New" or "Revised" License
9 stars 39 forks source link

openblas v0.3.21 #142

Closed regro-cf-autotick-bot closed 2 years ago

regro-cf-autotick-bot commented 2 years ago

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

Checklist before merging this PR:

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 code>@conda-forge-admin,</codeplease 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 code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name Upstream Version Current Version
ctng-compilers 12.1.0 Anaconda-Server Badge
openblas 0.3.21 Anaconda-Server Badge

Dependency Analysis

We couldn't run dependency analysis due to an internal error in the bot. :( Help is very welcome!

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/autotick-bot/actions/runs/2814277377, please use this URL for debugging.

conda-forge-linter commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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

I considered the following status checks when analyzing this PR:

Thus the PR was not passing and not merged.

mattip commented 2 years ago

ppc is failing tests with a segfault /bin/sh: line 1: 36986 Segmentation fault (core dumped) OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./test_sbgemm > SBBLAT3.SUMM

macOS is failing to find omp ld: library not found for -lomp

h-vetinari commented 2 years ago

Thanks @mattip. The segfault is the more serious of the two and I think we'll have to raise an issue upstream - especially since it only occurs for ppc in conjunction with INTERFACE64=1.

CC @martin-frbg

h-vetinari commented 2 years ago

No idea for the moment why openmp isn't being picked up on osx...

martin-frbg commented 2 years ago

Looks like the segfault is actually due to the test code itself not being ready for INTERFACE64 (using int rather than blasint), which would be a bit embarrassing but essentially harmless

martin-frbg commented 2 years ago

https://github.com/xianyi/OpenBLAS/pull/3718

h-vetinari commented 2 years ago

xianyi/OpenBLAS#3718

Thanks for the super quick handling! Just in case this is in doubt, a patch is completely fine for us, no need for a release.

h-vetinari commented 2 years ago

No idea for the moment why openmp isn't being picked up on osx...

I had a look at what changed in the build environment since the last successful build, and it's 99% the same, only difference is:

@@ -25,7 +25,7 @@
     mpc:                      1.2.1-hbb51d92_0          conda-forge
     mpfr:                     4.1.0-h0f52abe_1          conda-forge
     objconv:                  2.49-h940c156_1           conda-forge
-    openssl:                  3.0.5-hfe4f2af_0          conda-forge
+    openssl:                  3.0.5-hb81d4ab_1          conda-forge
     perl:                     5.32.1-2_h0d85af4_perl5   conda-forge
     sigtool:                  0.1.3-h88f4db0_0          conda-forge
     tapi:                     1100.0.11-h9ce4665_0      conda-forge

In other words, it uses the exact same build of openmp & all surrounding compilers as before.

@martin-frbg, did upstream OpenBLAS change anything about handling openmp since the last release?

mattip commented 2 years ago

did the macOS images themselves change to use a different OS version?

h-vetinari commented 2 years ago

did the macOS images themselves change to use a different OS version?

Good point, that did happen indeed, but I wouldn't have guessed that this influences detection of openmp... 🤔

h-vetinari commented 2 years ago

No change to the linking errors by downgrading the macos version

martin-frbg commented 2 years ago

Is that failing Mac build an ARM64 system ? I changed the MACOSX_DEPLOYMENT_TARGET for those to 11 (from previous 10.8) to get rid of linker errors involving chkstk_darwin https://github.com/xianyi/OpenBLAS/pull/3670 but I am not aware of anything else that could affect Macs

h-vetinari commented 2 years ago

I changed the MACOSX_DEPLOYMENT_TARGET for those to 11 (from previous 10.8) to get rid of linker errors involving chkstk_darwin xianyi/OpenBLAS#3670 but I am not aware of anything else that could affect Macs

That's definitely a possible source of issues - thanks for the info! I'm trying first to only bump the SDK, conda currently still supports much older osx targets, so bumping the deployment target that aggressively would need some discussion.

h-vetinari commented 2 years ago

That's definitely a possible source of issues - thanks for the info! I'm trying first to only bump the SDK, conda currently still supports much older osx targets, so bumping the deployment target that aggressively would need some discussion.

Ah wait, I saw just now that this only affects osx-arm; in that case it's probably not the (only) solution, because we had the same issue on osx-x86

isuruf commented 2 years ago

@martin-frbg, https://github.com/xianyi/OpenBLAS/pull/3721 should fix the build failure on macs

h-vetinari commented 2 years ago

@martin-frbg, xianyi/OpenBLAS#3721 should fix the build failure on macs

Thanks a lot @isuruf!

h-vetinari commented 2 years ago

BTW @martin-frbg, I just saw in the logs that

dynamic_power.c:200:6: warning: builtin '__builtin_cpu_is' needs GLIBC (2.23 and newer) that exports hardware capability bits
  200 |  if (__builtin_cpu_is("power9"))
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~

We're currently targetting an older sysroot/glibc (2.12), what is expected to happen if this detection based on __builtin_cpu_is is broken? Or does OpenBLAS hard-require glibc >= 2.23?

martin-frbg commented 2 years ago

@martin-frbg, xianyi/OpenBLAS#3721 should fix the build failure on macs

Thanks a lot @isuruf!

Oops, did not realize these were related. And such a tame PR title :)

martin-frbg commented 2 years ago

BTW @martin-frbg, I just saw in the logs that

dynamic_power.c:200:6: warning: builtin '__builtin_cpu_is' needs GLIBC (2.23 and newer) that exports hardware capability bits
  200 |  if (__builtin_cpu_is("power9"))
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~

We're currently targetting an older sysroot/glibc (2.12), what is expected to happen if this detection based on __builtin_cpu_is is broken? Or does OpenBLAS hard-require glibc >= 2.23?

Oh, bad things probably... let me see... according to gcc 9.4 onlinedocs, the function will return 0 for all types, which means detection returns NULL and the DYNAMIC_ARCH code will default to POWER8. Is that acceptable ?

h-vetinari commented 2 years ago

Unfortunately it seems I merged just as you were starting to comment - sorry.

Oh, bad things probably... let me see... according to gcc 9.4 onlinedocs, the function will return 0 for all types, which means detection returns NULL and the DYNAMIC_ARCH code will default to POWER8. Is that acceptable ?

Thanks for having a look. Since we're running tests here and in other feedstocks with this (e.g. numpy/scipy), I presume this works more or less, perhaps just a performance drop due to being less specialised? Not sure why, but I don't see the same warnings on Linux-x86.

Maybe @isuruf can give a more satisfying answer.

martin-frbg commented 2 years ago

That particular function call is only used on the POWER platform so you won't see the warning on x86. I expect bad things would happen if one tried to run the code on POWER6 with an older glibc, but even then one could override the failing autodetection by exporting OPENBLAS_CORETYPE=POWER6