Hacker News Reader

Comment by chubot | Hacker News Reader

I'm pretty sure RMS said something to the effect that the ship has sailed with Clang. There's no longer any point in trying to prevent people from using proprietary back ends with the GCC front end. If they want to do it, then they can do it with Clang, so there's no point anymore in trying to "adjust" GCC's architecture.

I believe a prominent example is NVidia's CUDA compiler. As far as I understand this is just a modest fork of the Clang front end and a big new LLVM back end, and it's proprietary.

However Google has developed an open source alternative CUDA compiler, which is also based on Clang/LLVM: https://research.google.com/pubs/pub45226.html

Also I would have thought that Clang already has LSP support for C++, but maybe I'm wrong.

View on HN

Another example are the companies selling compilers for embedded development.

Previously they had proprietary compilers or gcc forks that they weren't that happy contributing back.

Now they can have their proprietary clang forks and don't contribute anything back.

Plenty of slideware examples at LLVM conferences.

On one side clang was great for improving the whole safety and tooling story for C and C++.

On the other side, if clang was available to Brad Cox, NeXT would never had released Objective-C to the community.

> On the other side, if clang was available to Brad Cox, NeXT would never had released Objective-C to the community.

Actually the Stepstone "compiler" was a preprocessor that generated C (like cfront was for C++). Brad Cox never worked for NeXT.

The Objective C front end for gcc was written by Steve Naroff at Next. Later he and I persuaded Jobs that that front end should be merged into the official gcc tree, and so we (Cygnus) worked with NeXT to get merge them and, amazingly, produce Objective-C++ in the process.

Jobs was focused on the goal. When NeXT (and later Apple) were underdogs he was happy to embrace open standards (e.g. JPEG, MPEG, MPEG-3...) when it would help and outside proprietary standards when he thought it was needed (e.g. paid the rtf license).

Thanks for clarifying how everything went, and correcting my "what if".

> Now they can have their proprietary clang forks and don't contribute anything back.

References? Most of the "custom" compilers are based on some ancient version of gcc.

I haven't yet bumped into an embedded compiler that was clang-based.

> Plenty of slideware examples at LLVM conferences.

Well, the conference can obviously stop that, if they wish.

One example is the guys from Embecosm, http://www.embecosm.com/

Not everything they do comes back to LLVM, it depends on the customer willingness to let it happen.

Where do I find GPUCC so that I can install it?

I guess it's upstream now:

http://llvm.org/docs/CompileCudaWithLLVM.html

The team at Google published a paper in CGO 2016 detailing the optimizations they’d made to clang/LLVM. Note that “gpucc” is no longer a meaningful name: The relevant tools are now just vanilla clang/LLVM.

There is a Hello World program on that page, which looks good.

Reply on news.ycombinator.com