Am Mi., 18. Nov. 2020 um 12:17 Uhr schrieb David Chisnall <David.Chisnall at cl.cam.ac.uk>:> On 18/11/2020 18:03, Michael Kruse wrote: > > This is missing the probably largest group: Users of clang who compile > > clang themselves (e.g. because their OS does not come with a package > > for clang, or is too old) > > I think our target for this group should be that it is size 0. Windows, > macOS, and *BSD all have up-to-date packages of the latest version, as > do many Linux distros. We provide APT repos for Debian and Ubuntu. > What are the large platforms that do not have packages of the latest > release and how do we fix that?First, it is not rare that you are working on an LTS release, but need a newer compiler. I myself am still working on a remote machine using Red Hat EL7 with gcc 4.8 and no clang pre-installed. Since I am not the admin of that machine, I have to compile clang (and gcc) with a prefix in my home directory. Second, for OpenMP target offloading, we recommend users to compile the latest trunk because it is under heavy development. In practice, if you are using target offloading, you have to compile it yourself because it needs to match the installed version of CUDA (or ROCm) and I have yet to see a distribution where OpenMP target offloading works out of the box. Michael
On 18/11/2020 18:40, Michael Kruse wrote:> First, it is not rare that you are working on an LTS release, but need > a newer compiler. I myself am still working on a remote machine using > Red Hat EL7 with gcc 4.8 and no clang pre-installed.We build nightly packages for Ubuntu LTS releases, what do we need to do to add the same support for Red Hat?> Since I am not > the admin of that machine, I have to compile clang (and gcc) with a > prefix in my home directory.As I recall, nothing in the LLVM install hard codes the install location. Deb packages are just ar archives, RPMs are just cpio archives, so users without admin access could just grab the latest nightly package for their distro and extract it into their home directory. We could provide a script for that (or, to be more friendly, build a .txz from the same directory tree).> Second, for OpenMP target offloading, we recommend users to compile > the latest trunk because it is under heavy development. In practice, > if you are using target offloading, you have to compile it yourself > because it needs to match the installed version of CUDA (or ROCm) and > I have yet to see a distribution where OpenMP target offloading works > out of the box.That sounds unfortunate. I presume that there is a long-term plan for fixing this? David
Am Do., 19. Nov. 2020 um 03:33 Uhr schrieb David Chisnall <David.Chisnall at cl.cam.ac.uk>:> > Since I am not > > the admin of that machine, I have to compile clang (and gcc) with a > > prefix in my home directory. > > As I recall, nothing in the LLVM install hard codes the install > location. Deb packages are just ar archives, RPMs are just cpio > archives, so users without admin access could just grab the latest > nightly package for their distro and extract it into their home > directory. We could provide a script for that (or, to be more friendly, > build a .txz from the same directory tree).Why is this preferable over compiling from source? We provide documentation to compile from source, but not how to extract files from distribution packages and where clang expects them. Even if one would consider that, there are reasons to compile from source such as optimizing the binary for the concrete CPU (-match=native) and not having to trust a 3rd party that the compiled binary corresponds to the sources (not that I would argue like that, but I know people who compile from source, including their kernel, on principle).> > Second, for OpenMP target offloading, we recommend users to compile > > the latest trunk because it is under heavy development. In practice, > > if you are using target offloading, you have to compile it yourself > > because it needs to match the installed version of CUDA (or ROCm) and > > I have yet to see a distribution where OpenMP target offloading works > > out of the box. > > That sounds unfortunate. I presume that there is a long-term plan for > fixing this?I hope. It is somewhat difficult to provide offloading plugins for all vendors at the same time (Nvidia+AMD+NEC+...) that each also have different versions. Michael