31

I need some opinion. GCC was always a very good compiler, but recently it is losing "appeal". I have just found that on Windows GCC does not have std::thread support, forcing Windows users to use another compiler because the most exciting feature is still missing.

But why really doesn't GCC still have threads support under Windows? License problems? ABI incompatibilities? (Well there are already several cross-platform libraries using multithreading: boost, POCO, SDL, wxwidgets, etc. Wouldn't it be simple to use already existing, and MIT/libpng licensed, code to fit this hole instead of shipping GCC releases with no thread support?)

Recently, looking at compiler comparisons, GCC has the widest support for C++11 features with respect to other compilers, except for the fact that on Windows this is not true because we are still lacking atomics, mutexes and threads :/

I'd like to know more about this topic, but the only thing I can find is people asking for help because:

"thread" does not exist in std namespace

Looking at tickets tracking and mail discussions of GCC/TDM-GCC, there were requests for thread support since 2009. Possible that after 4 years still no solution? What's really happening?

Mat
  • 2,066
  • 2
  • 26
  • 31
CoffeDeveloper
  • 551
  • 1
  • 4
  • 10
  • 8
    gcc is still good, no matter what you recently found out. – ott-- Apr 21 '13 at 21:41
  • 1
    I just liked std::thread . that was not such hard feature to implement. Just take variadics templates and for example SDL thread and you can make a class equivalent to std::thread :/ – CoffeDeveloper Apr 21 '13 at 21:57
  • 13
    I would almost argue given the inability of average programmers to write reliable multi-threaded apps, no thread support is a bonus..... – mattnz Apr 21 '13 at 22:44
  • lol =) I've heard of bugs wich are in reality features, but never heard about missing features that are in reality features – CoffeDeveloper Apr 22 '13 at 08:14
  • 3
    you are complaining about libaries not specifically the compiler. – wirrbel Apr 22 '13 at 08:55
  • Do you select your tools based on appeal or whether or not they do they job you want? – Blrfl Apr 22 '13 at 12:51
  • GCC's popularity and usability is not questionable. But consideration is License. For details have a look to my answer. – Md Mahbubur Rahman Apr 22 '13 at 15:14
  • 2
    GCC is popular, that is true. But I wouldn't say, that it's been "always a very good compiler". Ages ago people were experimenting with ICC on Linux, because of slow and bloated binaries which GCC produced. OTOH, all major open source project use VS to compile Windows version of their code, again, because GCC produces slow bloat in comparison. – vartec Apr 22 '13 at 15:42
  • Good question, flame-bait title. – milleniumbug Apr 22 '13 at 19:30
  • Actually, gcc as of at least 4.8 has support for C++11 threads on Windows as long as the build you're using was configured for posix threads. –  Apr 21 '14 at 19:29

3 Answers3

29

GCC's popularity and usability is not questionable.

From https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build at http://code.google.com/p/mingw-builds/downloads/list supports threads.

But important consideration is License.

FreeBSD has an uneasy relationship with the GPL. BSD-license advocates believe that truly free software has no usage restrictions. GPL advocates believe that restrictions are necessary in order to protect software freedom, and specifically that the ability to create non-free software from free software is an unjust form of power rather than a freedom. The FreeBSD project, where possible, tries to avoid the use of the GPL (For details https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang-llvm)

Other important Considerations

From http://clang.llvm.org/comparison.html#gcc

  • The Clang ASTs and design are intended to be easily understandable by anyone who is familiar with the languages involved and who has a basic understanding of how a compiler works. GCC has a very old codebase which presents a steep learning curve to new developers.
  • Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.
  • Various GCC design decisions make it very difficult to reuse: its build system is difficult to modify, you can't link multiple targets into one binary, you can't link multiple front-ends into one binary, it uses a custom garbage collector, uses global variables extensively, is not reentrant or multi-threadable, etc. Clang has none of these problems.
  • For every token, clang tracks information about where it was written and where it was ultimately expanded into if it was involved in a macro. GCC does not track information about macro instantiations when parsing source code. This makes it very difficult for source rewriting tools (e.g. for refactoring) to work in the presence of (even simple) macros.
  • Clang does not implicitly simplify code as it parses it like GCC does. Doing so causes many problems for source analysis tools: as one simple example, if you write "x-x" in your source code, the GCC AST will contain "0", with no mention of 'x'. This is extremely bad for a refactoring tool that wants to rename 'x'.
  • Clang can serialize its AST out to disk and read it back into another program, which is useful for whole program analysis. GCC does not have this. GCC's PCH mechanism (which is just a dump of the compiler memory image) is related, but is architecturally only able to read the dump back into the exact same executable as the one that produced it (it is not a structured format).
  • Clang is much faster and uses far less memory than GCC.
  • Clang aims to provide extremely clear and concise diagnostics (error and warning messages), and includes support for expressive diagnostics. GCC's warnings are sometimes acceptable, but are often confusing and it does not support expressive diagnostics. Clang also preserves typedefs in diagnostics consistently, showing macro expansions and many other features.
  • Clang inherits a number of features from its use of LLVM as a backend, including support for a bytecode representation for intermediate code, pluggable optimizers, link-time optimization support, Just-In-Time compilation, ability to link in multiple code generators, etc.
  • Clang's support for C++ is more compliant than GCC's in many ways (e.g. conformant two phase name lookup).

From http://www.linuxquestions.org/questions/slackware-14/gcc-vs-llvm-931034/

  • The advantage of llvm/clang is its modular design, so it can be
    interfaced and used for example to create static code analysis tools, what becomes more and more important ()

From http://clang.debian.net/

  • clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc.
Community
  • 1
Md Mahbubur Rahman
  • 4,747
  • 5
  • 32
  • 38
  • 2
    Best answer ever! – Vorac Apr 29 '13 at 10:05
  • 3
    Just to be up-to-date: GCC tracks macros expansion since 4.8, with the option `-ftrack-macro-expansion`, now enabled by default :) – Morwenn May 27 '13 at 08:02
  • Another problem with trying to simplify the source tree at parsing time is that there are many situations where a bit of syntax should not generate any code *but* should affect what optimizations are allowed. If `foo` and `moo` are pointers to different structure types, both of which have field `bar` as part of their initial sequence, writing `*&foo->bar` and reading `*&moo->bar` should result in the read seeing the write, since the only effective type used in either access is the type of `bar`. GCC, however, seems to filter out the `*&` and thus percolates the types of `foo` and `moo`... – supercat Oct 25 '16 at 22:04
  • ...through the address-of operator, which is not justified by anything I can find in the Standard. – supercat Oct 25 '16 at 22:05
23

I understood that GCC is falling out of favour because the people maintaining it have become somewhat arrogant, and now that LLVM is here (and is very good) people are voting with the feet.

Slashdot had a discussion about LLVM's new support for C++11. _merlin says:

Oh I don't think anyone thinks it's evil, just that it's pure self-interest rather than generosity. GCC's phenomenal popularity has led to its maintainers growing massive egos and behaving like total [****]. Bugs are introduced faster than Red Hat and Apple can get patches for them accepted, and they have a nasty habit of not looking at bug reports, then closing them due to inactivity without actually fixing them

which chimes in with your observation about the 4-year delay.

Servy
  • 1,966
  • 14
  • 12
gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • You might also find http://developers.slashdot.org/comments.pl?sid=3669407&cid=43503547 (also by _merlin) to point out other problems with compiling for non-linux with gcc. –  Apr 21 '13 at 23:34
  • 3
    It's not just LLVM, Visual Studio Express Editions are another viable, gratis alternative (considering the question is specifically about `std::thread` on Windows which is supported in VS2012 EE) – MSalters Apr 22 '13 at 09:21
  • 1
    too bad VS2012 doesnt have full support for std::thread (e.g. no `thread_local` variables) – alrikai Jul 05 '13 at 23:52
  • Has this changed at all in the modern day? – Hashim Aziz Mar 18 '19 at 01:20
11

The reason why it takes a lot of time is because it takes a lot of work to get a solid foundation to build the headers on top of. The way mingw-w64 seems to bo is to build a solid pthreads-like library on Windows. There's less upstream grumpiness over that than introducing a dependency on the native threading of the Windows API.

mingw-w64 implements <thread> and the other C++11 headers on top of their own winpthreads library. This should be available for testing in both Mingw-builds and rubenvb's distributions of the mingw-w64 toolchain. I would recommend following the mingw-w64 mailing lists if you want to track where most of the work on native Windows GCC work is done.

The Qt Project has a wiki page detailing their current recommendation and an over view of GCC toolchains on windows, see this Qt Project wiki page.

Lars Viklund
  • 2,106
  • 1
  • 17
  • 14