Openblas: New release

[staticfloat]

Hello there,

Following the recently merged patches, it looks like some serious bugs have been fixed with respect to ppc64le support. Are there any plans to make a new release anytime soon?

[xianyi]

@wernsaar @martin-frbg Any suggestion?

I think we can release this week or next week.

btw. I am working support soft fp ABI form ARMv7 assembly kernels.

[martin-frbg]

Nothing truely important to expect from me at the moment, I may be able to pick up some recent netlib patches (the remaining lapacke updates from their PRs 118&120) over the weekend. If you happen to have the time, could you look at #1070 where one of your countrymen (thought he) had trouble expressing himself in english ?

[martin-frbg]

With respect to recent ppc64le bugfixes, IBM's Alan Modra warned in (forum thread linked from) #1078 that somebody still needs to go through all the .S files for POWER8 and apply similar corrections there.

[staticfloat]

Hmmm, actually, I also just tested the latest OpenBLAS develop branch on Julia, and I noticed some symbols seem to be missing. When trying to call symv on an ILP64 version of OpenBLAS, we cannot find symbols such as csymv_64_ and zsymv_64_ (which have the _64 suffix added by our build system). Looking at exports/gensymbol, it looks like these were changed on purpose because they are now provided in LAPACK, however the symbol renaming doesn't work on them anymore. E.g. if I do nm on my libopenblas, I see csymv_ and zsymv_, but there is no suffix applied to them. Is this a bug?

[martin-frbg]

Well, seems you are the first to miss them, but it does look kind of impractical that they were expressly dropped from the blasobj list without then placing them among the lapackobjs.

[staticfloat]

I've opened a PR which might or might not be the right way to do this here.

[martin-frbg]

Merged, thanks.

[staticfloat]

For the record, the merged PR has indeed resolved the missing symbols issue I had, so things are happy now.

[staticfloat]

The cleanup of ppc64le that has been made since v0.2.19 also solved another strange bug we were having where GCC 6.3.0's tree vectorizer was somehow triggering a memory overwrite bug in OpenBLAS; the latest master fixes it. Great work guys!

[martin-frbg]

All credit for that goes to @amodra I think :-)
I would still appreciate a response from @wernsaar regarding #1117 (the apparent fix I "stole" from his tree), and if nobody complains I intend to merge the Ryzen support from PR #1133 tomorrow (unless @xianyi beats me to it). All in all there should be more than enough reasons for a new release, and I hope it would also provide an opportunity for fixing the windows binaries on sf.net (issues #1112, #1073 and possibly #805)

[tmh1999]

Hi, is there any plan to release soon ? I am concerning about System z (aka s390x, aka z13) port. Is it stable enough to be included in the next release ? Thanks.

[pbregener]

I am also interested in hearing about the plans for the next release. I'm only using x86-64, but believe to remember that several important bug fixes and performance improvements were merged after the 0.2.19 release.

[pbregener]

Any update on this this? @xianyi @martin-frbg

[martin-frbg]

I believe I have to defer to xianyi on this (though I think I may be able to craft releases from his project in an emergency)

[staticfloat]

@xianyi when might we be able to get a new OpenBLAS release? Does there need to be testing done on a certain kind of system to ensure stability, or are we waiting for new features?

[staticfloat]

@xianyi Not to be a pain, but I think it would be helpful if there was a list of things that need to be done before the next release so that we know what to work on to push toward a new release.

[xianyi]

@martin-frbg , I think I finished ARM softfp abi code.

Is it ready to release OpenBLAS?

[martin-frbg]

@xianyi while I may well be mistaken, it looks to me as if you adressed the single precision implementations only, and similar work would be required for ddot,dscal etc. (cf. #1168) ?
(Though this need not delay the much-wanted release, just be mentioned in the release notes - same as the recent PPC fixes where some .S files from the original implementation still need review ).
I noticed that netlib-LAPACK is gearing up for a 3.7.1 release, and I am currently working on merging ReLAPACK (#788) but these too can go in after 0.2.20 is released.
Rereading this thread - would it be OK to cherrypick the fix for #1117 from wernsaar's fork before the release ?

[boegel]

follow-up in #1223?

[staticfloat]

Thanks guys!