Hacker News Reader

Comment by jason_slack | Hacker News Reader

Honest question: on OS X, Apple has embraced clang and not gcc anymore. When I use linux clang is also available.

Can anyone chime in about how a developer would choose gcc over clang (and vice versa). I have to admit that even though I write in c++, I seldom pay attention to which compiler I would use for x vs y feature, etc. Compilers feel like a black-box to me. I don't go inside it.

Edit: I don't know about Windows, I know gcc is available. I haven't looked if clang is.

Edit 2: Intel also makes compilers, to which I own, but never use. I guess I feel like I am not doing anything specific to Intel

View on HN

Right now, clang is missing several features that I care about, but most of the industry doesn't[1]. Clang is a 90% or maybe 95% solution, and my use cases aren't covered. So I don't use it. That said, I am grateful for the competition: GCC has definitely been getting better thanks to clang.

[1] Namely, -Wdouble-promotion, big-endian ARM interrupt handlers, -fstack-usage, -Og, -fno-delete-null-pointer-checks, -falign-functions

+1 for -fno-delete-null-pointer-checks

But actually, what I'd rather like is -fno-optimise-based-on-undefined-behaviour.

-fno-delete-null-pointer-checks

In my particular case, I'm programming in a microcontroller environment where there is ordinary RAM at the NULL address. Dereferencing NULL therefore doesn't halt the program at all.

AIUI, this code is not affected:

  X *foo = ...;
  if (foo) foo->bar();

But this code will be:

  X *foo = ...;
  foo->bar();
  if (foo) { ... }

Since foo is dereferenced unconditionally, the compiler is allowed to assume that it will not be null in the above code, and therefore the test on the third line to determine whether foo is null or not is useless and can be omitted.

Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?

There used to be a fairly broad warning (-Wunreachable-code), but it caused so many false positives and false negatives that it was removed.

The real case where it matters is where the "if (foo) { ... }" test happens in a function that's been inlined into the caller, but not all the callers do the foo->bar() dereference. So it's only being removed in some cases.

Same thing in say the Linux kernel, where gcc removing a NULL pointer check actually created a vulnerability: http://lwn.net/Articles/342330/

Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.

Your compiler, or rather your architecture definition supplied to the compiler, is broken. NULL should be an invalid pointer value — it need not actually be memory address 0. (The explicit constant 0 in a pointer context should be automatically translated by the compiler into this special invalid pointer value.) There have been several such architectures already, so this should not present an insurmountable problem.

Try "-fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks" and then see if your program gets slower.

That won't nearly get everything, but loop optimization in C relies on undefined behavior a lot of the time, so you'll get to see how much you need it.

GCC, from my experience, generates much faster binaries.

Clang is much faster at compiling though. It's a trade off.

Correction. Clang used to compile much faster years ago. But nowadays GCC-6 actually compiles faster than clang-3.8.0. See e.g.: http://hubicka.blogspot.com/2016/03/building-libreoffice-wit...

That was the case circa 2012 with Clang 3.1 and GCC 4.7, but both have closed the gaps. Clang generates code roughly as fast as GCC and GCC compiles about as fast as Clang.

funny how this opposite spectrum leads to https://upload.wikimedia.org/wikipedia/commons/7/7c/Vector_A...

risc / cisc gathered around each other, clang / gcc...

progress by antagonism

gcc generally provides somewhat better code than clang, both in runtime and in object size. Clang has traditionally done better at warnings and diagnostics, although gcc has definitely closed that space in the past few years (since 4.9 or so).

are there circumstances where a developer should compile their products with more than one compiler to flush out issues, potentially fine tune/optimize code, etc? I've never thought about doing this.

Yes, at least make sure that your code compiles and the tests pass on more than one. That way you're sure that you're not depending on peculiars of one compiler (their specific behaviors that are undefined in the standard, optimizer actions, etc).

And a nice way to run multiple compilers easily is by using a tool like Travis CI with their compiler matrix support.

https://docs.travis-ci.com/user/languages/c

When I was working on multi-platform console engines, I had no choice but to compile with several highly varying compilers. It teaches you very quickly how quietly compiler-specific extensions and quirks work their way into your code.

Also, different dev environments offer different tools. A nice benefit of running in lots of environments was that I often could pick between the best tools of any platform whenever I had a problem they could help solve.

At a previous job we ensured we got clean compiles with Visual C++, SPARCworks and xlc, even tho' all our customers were only actually interested in the Solaris version.

Yes; whenever they want to produce a higher quality product. Which I'd anticipate being "whenever possible", limited only by compiler extensions one has to use, and dev/target hardware.

From experience make sure you compile 32bit and 64bit versions too - this flushed out a surpring number of bugs.

I've worked at places where we maintained a dual build, VisualC++ and Linux gcc, because we wanted to be able to develop and run in multiple environments. That forces you to write clean standard-compliant code, although in some cases it could be a pain.

The one thing I hear mentioned is that GCC supports more processors than Clang does. I believe this is the reason that NetBSD and OpenBSD still use GCC.

What do you mean by support more processors?

The comment was referring to CPU architectures.

I understand that. Still, what was meant? C/C++ don't have mechanisms for automatic parallelization, or if there are obscure extensions they are not commonly used. Compilation is usually a single-processor task, with linear speedup obtained by doing multiple compilation units in parallel (make -jN). So in what way can a compiler be "better" for multi-processor / multi-core CPU architectures?

I believe that in this context, "more processors" meant "more different models of processors". That is, there exist processors for which gcc can produce binaries and clang cannot produce binaries.

Ah ok. More backends.

Well, support for more target architectures, really. I can easily imagine cases where a compiler could have multiple backends for the same target arch, so the number of backends could be misleading in that regard.

For a summary from the OpenBSD perspective, see here: http://marc.info/?l=openbsd-misc&m=137530560232232&w=2

Different set of bugs (I know of more annoying bugs in clang and libc++ than I do of their GNU counterparts, perhaps only because I know gcc better), different performance in the generated code. Try them both and benchmark, see which you like best. I believe you can get gcc from homebrew, but beware of linking gcc-built code with libstdc++ and not libc++.

http://stackoverflow.com/questions/18976922/how-to-use-the-g...

1. License. If you are worried about GPL (especially v3), then you are better off with clang.

2. GCC is generally considered to produce better binaries.

3. Smart projects will support both and test with both. Before, even though projects tried to be portable, GCC was the only compiler most developers had available. Now they have two (although clang does try to support almost everything GCC does, so it doesn't say a huge amount about portability).

4. If you want to quickly see whether an optimization was applied (like inlining or loop unrolling), looking at LLVM is more approachable, so clang is nice for that.

why would the GPL matter for using gcc? It's not like you're modifying, distributing, and selling forks of gcc, it's just a compiler.

You are using logic, not all decision makers do. Some hear "GPL" and react, "oh that's the viral license can't use anything with that".

See sibling comment.

Runtime code generation / JIT.

gcc also supports OpenMP 4.x and OpenACC, both of which are used extensively in the HPC world to support automated parallelization and offloading to accelerators like GPUs. clang only recently added support for OpenMP 3.1, and my understanding is that there are no plans for OpenACC support.

> Edit 2: Intel also makes compilers, to which I own, but never use.

I see this more and more often on Reddit, from posters I assume are millennials, and I am interested in the psychology of this error. Why do you put a "to" before "which"? You would not say "I own to an Intel compiler".

I never see people make this mistake with other pronouns, either: for instance, they will correct turn "I saw pg yesterday" into "pg, whom I saw yesterday". What is it about "which" specifically that makes it hard for kids to use?

This person made at least four other grammar errors. I don't think they are a native English speaker.

Neither am I. I would be curious to know if this particular error is associated with a particular mother tongue.

If their Github is anything to go by, they appear to work for a Chinese company.

IIRC gcc generates somewhat faster machine code.

clang is available for Windows as clang-cl from here: http://llvm.org/releases/download.html

Here's the status page for compatibility with MSVC (clang 3.9, i.e. current development version): http://clang.llvm.org/docs/MSVCCompatibility.html

Well I see your edit mentions Windows and that was the problem when I last tried clang. It failed to compile FFmpeg. I don't know whether that is because it doesn't work, or didn't work, or my package was just outdated. GCC works. And once you force gcc to have colored messages there seems to be little advantage to using clang over it.

Out of inertia, I use gcc on all three platforms and it has been good towards me. Sometimes I need to compile a specific library on OSX with clang, but it works just fine with gcc ones as well (using ar provided with XCode CLI Tools). Mind you that I use C, not C++ and I tend to grab a GCC snapshot now and then and compile it and use it like that.

It also depends a little bit on your style of programming. For example, in C code, I personally like using gcc extensions like nested functions. As far as I know this is not supported by clang (but perhaps someone more knowledgeble can chime in).

>nested functions

They are not supported. In C++11 you can use lambdas:

  auto const local_func = [&](...) {
    ...
  };

And then later:

  local_func(...);

Not only that but you can even create a struct inside a function and overload operator(). I don't know if this is possible in C++03 or not.

>I don't know if this is possible in C++03 or not.

It is/was. It could be used to manually create a lambda function.

But note that you cannot use such class as a template parameter, as it has no linkage. Which makes it mostly useless, since you usually want to use lambdas with templates.

This restriction has been lifted in C++11.

Inside of a function too?

Cool, thanks!

There are quite a few other compilers available, if you look into commercial UNIXes, embedded and real time OSes, game consoles, HPC.

Reply on news.ycombinator.com