Compilation error (observed from pasta-msm) about sppark HOT 9 OPEN

CC=gcc-12 CXX=g++-12 cargo build if anyone comes across this issue.

Right, this is what "pulling the "unsupported" card" means. I mean "don't use unsupported compiler" is logically equivalent to "use a supported one instead." BTW, setting CXX alone is sufficient.

On a related note, formally speaking setting CXX to a version other than system default is not actually a guarantee for success. The trouble is that rustc will call cc to link the final binary, and the CC variable has no effect on it. While mixing g++-12 and cc-13 as linker is a virtually-no-risk operation, you have to recognize it, and keep in mind that if you run into a problem, no matter how unlikely, it might be appropriate to instruct rustc to use the matching linker.

from sppark.

Hmmm... Is it actually so that nvcc is the only new component? I mean I'm using 12.3 and it's perfectly all right. Well, I don't have gcc 13, and it seems that it's gcc 13 that is the culprit...

from sppark.

Moreover, if I put together gcc 13.2.0 and nvcc 12.3 it says #error -- unsupported GNU version! gcc versions later than 12 are not supported. This is in a ubuntu:devel docker container... How come it lets you through with just a warning? Which distribution is it do you run?

from sppark.

My indication about updating nvcc 12.1 -> 12.3 was just for context, it's indeed not the only moving piece.

Here's the output of cargo clean && CC=/usr/lib/llvm14/bin/clang CXX=/usr/lib/llvm14/bin/clang++ cargo check:
https://gist.github.com/huitseeker/f65afe92e9275daa9e1a85ef8eaca698

huitseeker@sleipnir➜huitseeker/tmp/pasta-msm(main)» /usr/lib/llvm14/bin/clang++ --version                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   [11:15:02]
clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm14/bin

That of cargo clean && CC=/usr/bin/clang CXX=/usr/bin/clang++ cargo check:
https://gist.github.com/huitseeker/11c3e4cf73d8fc7a12424dfa53824deb

That later one is versioned thus:

huitseeker@sleipnir➜huitseeker/tmp/pasta-msm(main)» /usr/bin/clang++ --version                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              [11:13:03]
clang version 16.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Those warnings are indeed different from the gcc ouput.

from sppark.

Incidentally clang++ warnings were spotted today, as result of introduction of the .github/workflows/ci.yml that exercises both c++ and clang++. They will be resolved at a later point. But how do I reproduce the problem with gcc? Well, we're likely to pull the "unsupported" card on the basis of the #error -- unsupported GNU version!, question is rather if it's a learning opportunity [to make it future-proof]...

from sppark.

I'm running on Archlinux, which installation of CUDA indeed removes this warning:
https://gitlab.archlinux.org/archlinux/packaging/packages/cuda/-/blob/main/PKGBUILD?ref_type=heads#L130

With that said, despite NVIDIA being extra cautious, this has worked for about a year: https://gitlab.archlinux.org/archlinux/packaging/packages/cuda/-/commit/5c0d3a90e04541f8ab011b616c3f29b01c8af74b

On the other hand, could it be that replacing:

    std::unique_lock<std::mutex> lock(mtx);
    std::function<void()> func = work;
    fifo.emplace_back(std::move(func));
    cvar.notify_one();  // wake up a worker thread

Would suffice to lift the ambiguity?

from sppark.

I'm running on Archlinux, which installation of CUDA indeed removes this warning:

Well, then it's Archlinux's responsibility, isn't it? :-) But on a serious note, you have to agree that it's not really reasonable to expect this that we can do better than the vendor [Nvidia in the context]. Nothing prevents you from going "vigilante," but you have to accept the consequences. On a more practical note, it should be noted that gcc 13.2 has no problem compiling sppark itself, which compiles thread_pool_t.hpp, or pippenger.cpp, which also compiles thread_pool_t.hpp. It's specifically nvcc that manages to push gcc buttons and make it angry. Note that it complains even about this line. Note that in the pallas.cu context the line in question is merely parsed. I mean the compiler won't generate actual code for it... I might take another stab at it, unraveling the compilation path, if time permits, but for now I'm pulling the "unsupported" card. (But keep it open as a reminder ;-)

from sppark.

Archlinux cuda depends on gcc12 https://archlinux.org/packages/extra/x86_64/cuda/

Therefore CC=gcc-12 CXX=g++-12 cargo build if anyone comes across this issue.

from sppark.