

Porting LLVM, clang et al. to GNU/Hurd - redDragon
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/057901.html

======
lmm
I'm struggling to imagine the audience for this; other than compiler
researchers, LLVM's users seem to be primarily those who want to avoid using
GNU code (in the form of gcc, which while not without its flaws is still more
featureful and generally produces more performant code) for whatever reason
(e.g. Apple), while Hurd's only users are GNU devotees.

~~~
jevinskie
The clang static analyzer is the best you can find in the FOSS world and is
constantly improving. LLVM itself is multi-target with a single compiler
binary (llc), always handy for embedded developers. LLVM can target GPUs, and
the resulting binaries wouldn't care if the host OS was Linux or Hurd. Clangs
diagnostics are often better than GCC's but the GCC project is catching up
fast in that area. Finally, LLVM offers a JIT that projects can use as a
library. GCC offers compatibility, large target support, lots of compiler
extensions, and great code generation.

------
dschiptsov
btw, the current dev version of clang is broken for months. It crashes on a
failed assertion when I'm trying to compile erlang or mplayer+ffmpeg. It also
failed to build racket - the resulting binary eats all the memory and dies.)
Gcc does the job. So, it seems that while running after C++ features they
ruined the plain old C.)

~~~
stephencanon
It works great on my C sources; have you reported the failure(s)?

~~~
dschiptsov

      clang  -m64 -march=native -mtune=native -O3 -I/home/schiptsov/Compile/otp/erts/x86_64-unknown-linux-gnu    -D_GNU_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS  -Ix86_64-unknown-linux-gnu/opt/smp -Ibeam -Isys/unix -Isys/common -Ix86_64-unknown-linux-gnu -Izlib  -Ipcre -Ihipe -I../include -I../include/x86_64-unknown-linux-gnu -I../include/internal -I../include/internal/x86_64-unknown-linux-gnu -c beam/beam_emu.c -o obj/x86_64-unknown-linux-gnu/opt/smp/beam_emu.o
      clang: /home/schiptsov/Compile/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2050: bool <anonymous namespace>::LoopVectorizationLegality::canVectorize(): Assertion `TheLoop->getLoopPreheader() && "No preheader!!"' failed.

------
chris_wot
They had a working version to test on? Surely such a mythical beast doesn't
exist?

~~~
pjmlp
It does, it is just that most people tend to ignore Hurd anyway.

Personally I want Hurd and Minix 3 to gain support, as I feel that micro-
kernels are the way to improve operating system security.

The only successfully commercial attempts so far have been Symbian and QNX.

~~~
TheBoff
I was fairly sure that NT was originally going to be a microkernel, but it
ended up being really slow, so they had to push everything into a more
monolithic architecture.

~~~
seanmcdirmid
My understanding that this was mainly about moving graphic drivers back into
kernel space from user space (circa NT 4.0).

------
peterkelly
\def\Linux{GNU/Linux}

\def\Hurd{GNU/Hurd}

~~~
jedbrown

      \usepackage{xspace}
      \def\Linux{GNU/Linux\xspace}
      \def\Hurd{GNU/Hurd\xspace}

