OpenBLAS 0.3.24 Released With Intel Sapphire Rapids Improvements, Apple M2 Detection

[phoronix]

Phoronix: OpenBLAS 0.3.24 Released With Intel Sapphire Rapids Improvements, Apple M2 Detection

OpenBLAS 0.3.24 is now available for this latest open-source BLAS and LAPACK implementation known for its advanced CPU optimizations and extensive tuning for providing for very speedy linear algebra kernels...

https://www.phoronix.com/news/OpenBLAS-0.3.24-Released

[oleid]

LLVM 17 compilation support

Each time I read something like this I recall the people the keep praising the advantage of a C or C++ standards when it comes to compatibility and talk garbage about languages, which have only one official implementation. 🤔

[coder]

Each time I read something like this I recall the people the keep praising the advantage of a C or C++ standards when it comes to compatibility and talk garbage about languages, which have only one official implementation. 🤔

You're:

1. excluding the very next words, which were "including for its Flang Fortran compiler". If you look at the release notes, they suggest that support for Flang was the main aspect of LLVM support that changed.
2. being hypebolic. Looking at the recent PRs, all I see that changed were some compiler options to better tune code performance with Clang. That really has nothing to do with the portability of the code, itself.

It seems to me like you're trying to work an agenda, rather than raising a matter of genuine concern. Otherwise, you'd have dug into the changeset to check if it actually represented a code-portability issue, before raising the spectre of such.

[oleid]

It seems to me like you're trying to work an agenda, rather than raising a matter of genuine concern. Otherwise, you'd have dug into the changeset to check if it actually represented a code-portability issue, before raising the spectre of such.

Calm down again. I was half joking. I use C++ every day at work and am aware of the differences between clang, gcc and msvc. Fortunately, the most common differences that occur in everyday life are usually only missing includes.

Nevertheless, clang-16 and later will be a challenge for Linux distributions due du changes in defaults. What was a warning before is now an error. Take Gentoo for example:

https://bugs.gentoo.org/870412

https://wiki.gentoo.org/wiki/Modern_C_porting

[coder]

clang-16 and later will be a challenge for Linux distributions due du changes in defaults. What was a warning before is now an error. Take Gentoo for example:

https://bugs.gentoo.org/870412

https://wiki.gentoo.org/wiki/Modern_C_porting

I don't know Gentoo, but I'm sure their build scripts have some system-wide defaults. The natural way to handle this would be to globally override the promotion of that warning to an error, or simply disable the error altogether, until all the instances have been hunted down and addressed.

For most of those packages, I'd imagine the upstream has already been fixed. So, that should just mean they have to fix a tractable number of instances before they can disable their override.

[oleid]

I don't know Gentoo, but I'm sure their build scripts have some system-wide defaults. The natural way to handle this would be to globally override the promotion of that warning to an error, or simply disable the error altogether, until all the instances have been hunted down and addressed.

Sure, one can add overrides, but that's not the point.

For most of those packages, I'd imagine the upstream has already been fixed. So, that should just mean they have to fix a tractable number of instances before they can disable their override.

According to Fedora, affected projects are in part unmaintained.

https://lists.fedoraproject.org/archives/list/[email protected]/thread/TLM5TLSK4BISE436KGTYI7CA7RQGKK5L/

But why I brought this example up is that you cannot be sure that your code will compile with recent compilers. Maintainer interaction is required. Sadly, C++ as well as C are not exceptional good here. While most breakage is simple enough, sometimes deep knowledge of the code is required. In this particular case non-standard GCC extensions are to blame.

[coder]

But why I brought this example up is that you cannot be sure that your code will compile with recent compilers.

Okay, the additional context helps. So, these are packages using constructs deprecated by C89 and removed in C99, then? In that case, it's reasonable that they don't compile, if they're using crap that should've been removed over 30 years ago. It's not Clang's fault.

Again, you're just trying to work an agenda. This has nothing to do with OpenBLAS or their changes. Not helpful.

If you're so butt-hurt about this topic, then please post in the proper thread about it, instead of wasting people's time by whining elsewhere.

https://www.phoronix.com/news/Fedora...posal-Modern-C