Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward _FORTIFY_SOURCE Parity Between Clang and GCC

developers.redhat.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#21

Post by comex »

chungy wrote: post #16
pcwalton wrote: post #12

Earlier quoted context omitted.

Well, at this point Clang is the one more likely to create a monoculture, not GCC.

Probably doubtful. I bet GCC is used at least 10× as much as Clang.

GCC is still dominant in the desktop Linux world and embedded. But Clang is the default compiler for:

- Apple platforms

- Android (at least for the NDK used by third-party developers)

- PS4

- Nintendo Switch

- WebAssembly (there's no official "default", but GCC doesn't support it)

- eBPF (at least, GCC didn't support it until a few months ago)

Oh, and Google uses Clang to build Chromium for all of its supported platforms (Windows, Mac, Linux).

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#22

Post by pjmlp »

chungy wrote: post #16
pcwalton wrote: post #12

Earlier quoted context omitted.

Well, at this point Clang is the one more likely to create a monoculture, not GCC.

Probably doubtful. I bet GCC is used at least 10× as much as Clang.

Not really, clang is very appealing for companies that aren't willing to give all their crown jewels to upstream.

Everyone that can move away from basing their toolchains has already moved into clang, or is in process of doing so.

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#23

Post by pjmlp »

comex wrote: post #21
chungy wrote: post #16

Earlier quoted context omitted.

Probably doubtful. I bet GCC is used at least 10× as much as Clang.

GCC is still dominant in the desktop Linux world and embedded. But Clang is the default compiler for: - Apple platforms - Android (at least for the NDK used by third-party developers) - PS4 - Nintendo Switch - WebAssembly (there's no official "default", but GCC doesn't support it) - eBPF (at least, GCC didn't support it until a few months ago) Oh, and Google uses Clang to build Chromium for all of its supported platf…

Android is fully clang nowadays, Google's fork of Linux kernel has been cleaned from GCC dependencies.

There were a couple of talks about it a couple of years ago.

2017 LLVM Developers’ Meeting: “Compiling Android userspace and Linux kernel with LLVM", https://www.youtube.com/watch?v=6l4DtR5exwo

"LPC2018 - Clang+Linux", https://www.youtube.com/watch?v=SSWUrWqnSz0

EDIT: typo and link for the mentioned talks.

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#24

Post by pjmlp »

favorited wrote: post #14
inetknght wrote: post #6

Earlier quoted context omitted.

> Is it leading to more features and better compilation than would be the case if there was just one compiler toolchain? I would argue that the pace of C++ compiler development has significantly increased since clang was introduced. I would surmise that elimination of GCC or Clang -- in the way that Chrome has resulted in the elimination of more than one competing browser -- would be detrimental to C++ as a whole. An…

Though obviously not because of Clang, the pace of C++ itself significantly increased since Clang was introduced.

However, because Clang, we have finally IDEs caughting up with Energize C++ and VA for C++ v4 ideas, a couple of decades after they shown what would be possible with C++ when one isn't constrained to UNIX mentality of development.

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#25

Post by pjmlp »

cycloptic wrote: post #15
jhasse wrote: post #7

Earlier quoted context omitted.

Clang can't copy from GCC due to the different licenses. GCC can't copy from Clang due to the FSF requiring a copyright assignment.

Neither of those are significant -- both can be forked if it becomes necessary. GCC has a long history of forks, and half the reason clang is becoming popular is because the downstream vendors didn't like GPL and wanted to make proprietary forks.

And GCC only became popular because UNIX vendors, starting with Sun, decided to sell the UNIX SDK separately from the base OS.

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#26

Post by littlestymaar »

jhasse wrote: post #8
unixhero wrote: post #2

Is it good for both, Pareto optimal, or is it bad for GCC that Clang is catching up? But if Clang is catching up, is that really bad?

It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…

> GCC and MSVC will die and there will be only one compiler on all platforms

That sounds like bad for C++ developers: competition is what made clang as good as it is now, and GCC improved a lot since Clang's threat happened. Also, Clangs bugs would become the de facto standard (this is happening right now on the web with Chrome).

Monocultures are harmful…

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#27

Post by inetknght »

pjmlp wrote: post #24
favorited wrote: post #14

Earlier quoted context omitted.

Though obviously not because of Clang, the pace of C++ itself significantly increased since Clang was introduced.

However, because Clang, we have finally IDEs caughting up with Energize C++ and VA for C++ v4 ideas, a couple of decades after they shown what would be possible with C++ when one isn't constrained to UNIX mentality of development.

What do you mean?

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#28

Post by rurban »

unixhero wrote: post #2

Is it good for both, Pareto optimal, or is it bad for GCC that Clang is catching up? But if Clang is catching up, is that really bad?

I doubt that you can fault clang with this behavior, because clang has a proper constexpr detection in C also, gcc only on C++.

So clang detects much more optimization opportunities with constant arguments, making it about 20x faster on the typical memcpy sizeof,... It's even faster than the glibc HW specific vectorized assembler optimizations, because the compiler knows much more than glibc, e.g. alignment, size. asm is an optimization barrier.

This is probably the reason clang has a different bos check than gcc.

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#29

Post by pjmlp »

inetknght wrote: post #27
pjmlp wrote: post #24

Earlier quoted context omitted.

However, because Clang, we have finally IDEs caughting up with Energize C++ and VA for C++ v4 ideas, a couple of decades after they shown what would be possible with C++ when one isn't constrained to UNIX mentality of development.

What do you mean?

I mean this,

https://www.youtube.com/watch?v=pQQTScuApWk

http://dreamsongs.com/Files/Energize.pdf

http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review

Basically Smalltalk like development experience, just for C++. Too advanced for early 90's computers (it demanded very high end hardware).

Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC

#30

Post by jhasse »

littlestymaar wrote: post #26
jhasse wrote: post #8

Earlier quoted context omitted.

It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…

> GCC and MSVC will die and there will be only one compiler on all platforms That sounds like bad for C++ developers: competition is what made clang as good as it is now, and GCC improved a lot since Clang's threat happened. Also, Clangs bugs would become the de facto standard (this is happening right now on the web with Chrome). Monocultures are harmful…

Competition is good, sure. But focusing the limited developing resources on one compiler, too. Without parallel universes it's hard to know what actually leads to a better compiler.
Post reply on HN