8 ms·

GCC 8.2 Released

142 points by edelsohn 8y ago

pyler 8y ago
And LLVM 7.0 rc 1 soon too - Aug 1 :)
jhoechtl 8y ago
Can anybody comment on the love for Clang vs. the declining importance of GCC? As it seems to me: GCC supports more platforms GCC creates more performant code Is it a license thing or a technical driven issue?
- quietbritishjim 8y ago
  As I understand it, one benefit of LLVM is that it has a cleaner backend interface, so it is easier to create a new compiler by using LLVM as your backend rather than GCC's backend. (In case it is not clear, just to be explicit: LLVM corresponds to only the backend part of GCC. Clang+LLVM correspond to the whole GCC C++ compiler.)
- pjmlp 8y ago
  License mostly. Given the amount of BSD deployments, I bet if Linux never happened, I would still be using Solaris, Aix, HP-UX, ..., as I don't imagine UNIX vendors would have been so generous with the *BSDs.
- hak8or 8y ago
  More performant I am not sure. Would have to see specific benchmarks comparing and the assembly for the newest gcc and newest clang. The reaosn why I vastly prefer clang is for three main reasons. Firstly, clang and llvm are written in c++ so it's much easier for me to work with. Secondly, it has proper documentation on how to, for example, add new optimization passes or adding a new instruction. This includes tons of talks and presentations on doing this live. Thirdly, the tooling for it is great, such as clangd, llc, lld, clanggtidy, etc. Gcc seems to have none of this. Oh, and almost forgot, most importantly llvm + clang is actually open source (more open) via a MIT license instead of gpl.
  - fs111 8y ago
    > Firstly, clang and llvm are written in c++ so it's much easier for me to work with. Why is the implementation language important to you as a user?
    - endorphone 8y ago
      Their interest seems to be primarily in alter the toolchain itself. To make this a multi-use comment, I'll also reply to GP and say that in every single case where I've benchmarked time sensitive code, GCC has generated faster, tighter code. I still primarily use clang for other reasons, but saying that GCC is more performant seems to be entirely valid.
    - maxerickson 8y ago
      The answer is in the paragraph you quoted from. "work with" includes extending the implementation.
  - callinyouin 8y ago
    I was with you until the end of your comment: > llvm + clang is actually open source (more open) via a MIT license instead of gpl How is a license that allows someone or some corporation to take some code, add to it, and make those additions proprietary "more open" than a license that specifically disallows that type of scenario? The GPL ensures that derived code stays open while MIT does not. In my eyes, that's "actually open source". I can see the argument that licenses like MIT allow consumers of some piece of code more freedom to do as they please, but that hardly makes it more open.
    - protomyth 8y ago
      How is a license that allows someone or some corporation to take some code, add to it, and make those additions proprietary "more open" than a license that specifically disallows that type of scenario? This gets argued all the time. What the corporation did was freedom for them not the code. GPL protects the code, MIT/BSD protects the people. Depending on your definition of "freedom" you will prefer one over the other.
- bluescarni 8y ago
  I would not be so sure about the declining importance of GCC. GCC has caught up a lot with clang in the last few years, from the quality of error messages, to standard compliance, compilation times, tooling, sanitizers, etc. IME GCC tends to produce faster code in practice, even if clang is often able to out-smart GCC in many areas (e.g., IIRC heap elision was first introduced in clang). GCC has a huge amount of inertia behind it, it's still the only compiler officially supported for compiling the Linux kernel, and, as long as the GCC developers don't stop improving it, it will be difficult for clang to take its role as "default" compiler, at least in Linux environments. I use them both daily and I am really happy that we have the possibility of freely choosing between two such amazing projects. It would be a step backwards if one of them ended up fading away.
  - nwellnhof 8y ago
    Compilation times? I thought that compliling with GCC has always been faster than with clang, at least in the general case.
    - ebikelaw 8y ago
      For C++ in my experience clang is much faster, especially for plain (unoptimized) builds.
      - dman 8y ago
        That has reversed in the last few releases of clang for my codebase.
        ebikelaw 8y ago
        Because gcc got faster or because clang got slower?
        Kranar 8y ago
        Because clang got a LOT slower and GCC got a bit faster. clang used to be incredibly fast and used little memory consumption, but recent versions have seen the compiler regress in both areas. On the other hand clang does a lot more now than it used to so it's somewhat justified. My own experience with a substantial codebase (1+ million lines of code) is MSVC uses the least amount of RAM, followed by clang and then GCC. For performance in terms of compiling/linking it's GCC/clang tied and then MSVC from fastest to slowest.
- readittwice 8y ago
  I guess both. GCC is very good for compiling C/C++ to machine code. But if you want to write a new language and reuse an existing compiler pipeline (Rust, Swift,..) or write a new tool based on a C++-parser (clang-format, clang-tiny, clangd,...) then LLVM is the way to go. LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end. GCC could have done that too: they didn't for political reasons. Why? Someone could have used GCC's C++ front-end for its proprietary compilation pipeline. Today this is nearly impossible to change in GCC. There are also some other advantages for LLVM I like: it supports multiple architectures in a single binary. With GCC I need to compile the compiler either for x64 or arm but not both. GCC is still great but it's not surprising that LLVM is so successful.
  - baq 8y ago
    you're of course right except the OP asked about clang and not llvm. clang frontend could generate postprocessed c and pass it into gcc for whatever that's worth.
    - jjuhl 8y ago
      The reverse has actually been done: https://dragonegg.llvm.org https://dragonegg.llvm.org
  - admax88q 8y ago
    > LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end. You're implying that GCC doesn't have a separation between language front-end and compilation back-end, but that's not true. GCC has a consistent internal representation known as GENERIC where the front-ends and back-ends meet just like LLVM.
    - monocasa 8y ago
      And GIMPLE... and RTL... And there's three separate forms of GIMPLE while you're at it. It's way easier to work with LLVM IR.
    - 8y ago
- tbrock 8y ago
  As someone who used to write c++ these are the reasons clang was great for development: - compiles faster - better error messages - tooling (clangformat) is great When it came time to cut a release binary you could always also build with gcc
  - ebikelaw 8y ago
    This is what I do. I use clang for everything except the final release. I get clang's speed and superior error messages while I'm editing code, and I get the very slightly, but measurably faster code generated by GCC.
  - HelloNurse 8y ago
    I've always used gcc on all platforms for C and C++, but since last year I also use clangformat. On the other hand, the effort of learning clang options, error messages and paths in order to have two compilers available can wait indefinitely until I really need a second opinion about some compilation error; so far it hasn't happened.
    - ebikelaw 8y ago
      You could build with bazel, which ships compiler configs for clang and gcc on linux (among other combinations) in its "CROSSTOOL"[1] file. Then it's trivial to switch compilers with one argument. This feature is a result of Google's years-long support of both GCC and clang for its own build, test, and release. $ bazel build --compiler=my_favorite_compiler //my/fine:program 1: https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain https://github.com/bazelbuild/bazel/wiki/Building-with-a-cus...
      - HelloNurse 8y ago
        Sorry, I lost you at "bazel". Do you believe constructing clang command lines in addition to gcc command lines is harder than setting up a particularly complex build tool like Bazel? Not to mention that it doesn't appear to support GCC and Clang on Windows.
- simias 8y ago
  Be wary of the optical illusion of the hype cycle, if you base yourself on HN's frontpage you'd think that Rust is more important than C++. In my experience GCC is still the default C and C++ compiler on Linux in most of the industry. If it ain't broke, why change it? Even though I still use GCC to build by C code I'm very happy that LLVM exists, it brought some new blood and much needed competition to the FLOSS compiler scene. It also gave a better architecture to build on if you want to create a new language, it's great that a language like Rust for instance can generate such good machine code by building on top of the LLVM backend. In the GCC-only days the easiest way to create a new compiled language was to emit C as an intermediary target...
  - haeffin 8y ago
    Depends on what your industry is. If you're compiling c++ for mobile, clang is pretty much your only choice for iOS and the default choice for Android ...
    - IshKebab 8y ago
      And the default on OSX.
      - JdeBP 8y ago
        ... and indeed on several of the BSDs. It has been the default compiler in base on FreeBSD since version 10, and FreeBSD is now built with it. There was also a push back around 2014 or so to get much of the ports tree built with it, too. DragonFly BSD has been buildable with clang since around 2014, albeit using clang from packages/ports. In 2017 (release 50) the DragonFly people started work on pulling it into base. OpenBSD switched building on x86/amd64 to clang in 2017 and building on armv7 to clang in 2018. NetBSD has included clang in base but as far as I know does not (yet) build with it by default on any architecture.
        simias 8y ago
        I only mentioned Linux because I knew that my argument wouldn't work for BSDs! But in my defense the situation, at least originally, was more political than technical (at least as far as FreeBSD was concerned, I don't follow the other BSDs too closely). GCC switching to the GPLv3 was a big no-no for many people in the BSD world. As a result they were at the forefront to port the system to clang since they were stuck with an obsolete GPLv2 GCC version.
- IshKebab 8y ago
  GCC is still important, but yeah Clang is definitely more popular and gaining popularity. I don't think the performance difference between them is significant, but Clang is much nicer if you want to use it as a library, add a new backend, etc. Basically if you want to do anything other than run it from the command line. Oh also, Clang does cross-compilation in a not totally insane way. I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years.
  - gmfawcett 8y ago
    > I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years. Let's hope not. The healthy competition between the two projects has been a huge boon for the OSS community.
  - aseipp 8y ago
    > I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years. It will not be, because LLVM does not align with the goals of the FSF and GNU projects. A free compiler under a free license is a pretty central project for them. (Besides that, making predictions 10 years out into the future of software seems meaningless. Saying "this thing might still be around in like 2 decades, or not" is... not particularly noteworthy, nor damning) Plus, I simply see no reason to believe this, even aside from that. If anything, GCC development has gotten far more active and improved greatly in the past few years, with consistently high quality releases, each bringing in major features, and adopting work from Clang, and bringing in their own unique work. It would seem each of these projects has livened up quite a lot over time and are offering higher quality than they ever have before. What reason do you have to believe it will be completely abandoned? Just because there's an alternative available? That never happened with Linux, either...
- zeveb 8y ago
  I think it really does boil down to the license: Apple absolutely hate copyleft, so they poured money into Clang. It's sad, really — look how old the bash & emacs are in macOS these days. And I really don't think that copyleft would hurt Apple: what compiler technology do they want to keep proprietary?
  - tzs 8y ago
    Apple started heavily investing in clang and friends because they wanted a compiler suite that was more modular than gcc and that could be used as a library in other things. They wanted to do things like take chains of filters in Core Image and JIT compile them into a single optimized filter that could target the CPU or the specific GPU in that Mac. They wanted to use the compiler's parser as a library in Xcode to handle things like syntax highlighting. Gcc could not do these things as it was at the time. The different parts were tightly coupled in ways to make it hard to separate things out. People had proposed making it more modular but the gcc devs rejected them, with RMS making it clear that the design was the way it was in order to make it harder for proprietary programs to have ways to use gcc's parts. Apple could have forked gcc and changed it to be more modular, but that would have required a lot of changes and a lot of work, and since it would not be accepted upstream they would probably have to do a lot of work every time there was a significant gcc update. It made much more sense in every way for them to go with clang and LLVM, because those were designed to allow the kind of modular, library use that Apple wanted.
- bgongfu 8y ago
  Two words, nested functions. They should have been in the C standard a long time ago, solving the same problems without them is a major pain. And even though Clang supports most of the rest of the GCC extensions, they stubbornly refuse to touch nested functions. That and the code of conduct social justice warrior bullshit they've been pulling lately keeps me away from Clang these days.
- Panino 8y ago
  Among other answers, clang supports -Weverything, which I was using just last night.
- jlebar 8y ago
  As a compiler hacker, I'll posit that LLVM is far easier to hack on. And of course the licensing makes a huge difference. So in terms of mindshare among people who are doing compilers, it's kind of a no-brainer.
- iforgotpassword 8y ago
  GCC progress was pretty slow before the rise of clang. Clang introduced many features that werent really on the radar of GCC, like better formatting of error messages, tight integration of tools like thread and address sanitizer, and in some areas even more and better warnings. Meanwhile - at least for a short period - gcc was on this optimization fad where they'd just take any occurrence of UB as a reason to silently eliminate chunks of code and render the whole program useless in some cases. With 4.8 they even broke SPEC 2006. The GCC folks always argued that doing so is legal by the standard, but eventually there was enough backlash that the worst instances of such aggressive optimizations were removed.
  - gnufx 8y ago
    The case I know of with SPEC was non-conforming code, not undefined behaviour. You really can't hold gcc responsible for bad code, though there's often a workaround like -fno-aggressive-loop-optimizations/-Wno-aggressive-loop-optimizations in that case. I'm glad GCC optimizes well and takes advantage of language definitions (specifically Fortran's) while being more reliable than ifort which gets lionized for optimization.
    - iforgotpassword 8y ago
      That's not the point. Of course you should write proper code, not do goofy things with pointers etc. But what I don't think was to excuse was that the compiler did this without warnings. And again the GCC folks' reply was "well you can crank up the warnings with -Wwhatever-the-hell". But that's just plain stupid. Any time the compiler removes code because of UB, non-conformance or specific interpretation of ambiguous specs in the C (or whatever) standard, a warning should be emitted by default, because it's pretty much guaranteed that the coder made either a blatant mistake or tried to do stuff that's simply wrong, again either by unawareness or by expecting the compiler to still emit some code that will at least work on their specific platform.
      - gnufx 8y ago
        I always advise turning on all warnings and maybe disabling them selectively, and using any static or dynamic analysis available (and understanding the warnings). Compilation time won't catch a lot of things anyhow, and most people just ignore warnings. It's a matter of judgement whether to issue specific warnings by default, but I don't want the noise from things like intentionally elided code from compile-time constants. In the case of aggressive-loop-optimizations I'd have thought the argument would be whether it should be on by default, or at something like -O2. [On my first workhorse systems, reading past the end of an array, as in the SPEC case, gave a hardware error if you didn't disable that.] Incidentally, ifort turns on (or used to) generally-invalid optimizations without warning, which GCC doesn't, and the first question to ask about user complaints of SEGVs on the systems I support is "ifort?" if only because of an optimzation which is valid but hits typical resource limits.
paulirwin 8y ago
Here are the release notes: https://gcc.gnu.org/gcc-8/changes.html#GCC8.2 https://gcc.gnu.org/gcc-8/changes.html#GCC8.2
- majewsky 8y ago
  Mods: Can you change the submission to point to this instead?
  - sctb 8y ago
    Sure thing. Thanks! Updated from https://gcc.gnu.org/ml/gcc/2018-07/msg00378.html https://gcc.gnu.org/ml/gcc/2018-07/msg00378.html.
thestoicattack 8y ago
> When reporting on mismatching template types, the C++ compiler will now use color to highlight the mismatching parts of the template, and will elide the parameters that are common between two mismatching templates, printing [...] instead I'll be interested to see if [...] can make instantiation error messages a lot smaller. I hope so. Also: > AddressSanitizer integration for std::vector, detecting out-of-range accesses to the unused capacity of a vector.
- karrotwaltz 8y ago
  The most verbose type of template errors I can think of are instantiation errors with multiple candidates and type deduction failures. In these cases there won't be any elision so it won't help much. I still hope one day we'll see GCC & clang implement some kind of parsable diagnostic output (e.g JSON). Simply folding all the candidates on a UI would be a massive step forward in reading template errors.
  - jcelerier 8y ago
    > Simply folding all the candidates on a UI would be a massive step forward in reading template errors. well... that's already what happens if you use an IDE ? That's at least the case on Qt Creator
    - karrotwaltz 8y ago
      I've heard a lot of good about QtCreator lately, from multiple people, I'll give it a try soon. Still, some parsable output would be great for many cases, a CI with diagnostic on a web page for example
  - Uberphallus 8y ago
    I'll be happy if the mismatching template types are simply aligned in two lines so it's easy to spot the differences.
shawabawa3 8y ago
Seems like a minor bugfix release, not what special relevance or interest this has
SloopJon 8y ago
Meanwhile, RHEL 7 uses GCC 4.8, which first shipped five years ago. How about the Red Hat Developer Toolset? Is that pretty commonly used, or do most Red Hat users stick with the default packages?
- batbomb 8y ago
  SCL/devtoolset is common.
- misnome 8y ago
  Lucky you. We’re stuck on RHEL 6. That’s GCC 4.4. And nobody we knows installs the toolset (I think the target user also needs to have it, because C++ libs?)
  - gusmd 8y ago
    Nope, your users need not have the toolset, that's the beauty of it! It creates binaries compatible with any distribution newer than the machine where you are compiling. E.g., if building on CentOS 6.7, anyone on 6.7+ can run your binaries. We also have an application stuck on RHEL 6 because of end-users, and I'm happily using devtoolset-7 which gives me GCC 7.x, and quite a bit of C++17 support :) Edit: My understanding is that it achieves that by statically linking in the "newer" parts of libstdc++.
- innot 8y ago
  The tool we develop at work has recently moved from RHEL 5 to 6 as the bottomline supported release. For us that meant a switch from GCC 4.8 to 6.3. So it's not that bad. And when we switch to Red Hat 7 in the next 3-4 years we might start using GCC 8 with all those cool new features!
pyler 8y ago
This release also fixes LTO bug with large binaries
bluecalm 8y ago
Is there any significant work done on GCC optimizer these days? Most of the changes in recent releases are about nicer error messages (which I love), sanitizers/UB detection (which I also love), new C++ features support (which I think is waste of brain power and time but well, most people like it) but there is little in optimizer department. From me experience GCC generates by far the fastest code (faster than Intel, Clang and Visual Studio). I realize it's hard to make progress after so many years but I am wondering if there is any promising direction which is researched these days or is it only about small fixes here and there.
- rurban 8y ago
  There needs to be work done, because for my usecases icc is usually a few percentages faster and newer clang almost twice as fast, with proper constexpr support. It's only memset, memcpy though, so who cares.
  - rurban 8y ago
    To the downvoters: This is the benchmark where GCC looses big time to clang: https://github.com/rurban/safeclib/blob/master/tests/perf_memcpy_s.c https://github.com/rurban/safeclib/blob/master/tests/perf_me... My clang compiled memcpy_s is faster than the handoptimized glibc assembler and twice as fast than the GCC version. So with a proper compiler you can get rid of handoptimized unportable optimizations easily. In this case memcpy, but also memset, memmove, memchr, ...
- benchaney 8y ago
  Optimizer improvements are generally added to major version releases. For example if you look at the 8.1 release it has a number of optimization improvements [0]. Not sure how much focus that is receiving right now though. [0] https://gcc.gnu.org/gcc-8/changes.html https://gcc.gnu.org/gcc-8/changes.html
rurban 8y ago
Tile-Gx is dead? That's sad and a bit early. Afaik MikroTik routers, the fastest routers available, are still selling.
112233 8y ago
Have they added a way to turn off spellcheck suggestions yet? Compiling with newer gcc feels like some monty python skit: #include <stdio.h> int main() { retrun 0; } $ gcc a.c a.c: In function ‘main’: a.c:2:14: error: ‘retrun’ undeclared (first use in this function); did you mean ‘setbuf’? Say gcc, why don't you try 'setbuf' yourself before suggesting it? Ugh...

142 points by edelsohn 8y ago

And LLVM 7.0 rc 1 soon too - Aug 1 :)

Can anybody comment on the love for Clang vs. the declining importance of GCC? As it seems to me: GCC supports more platforms GCC creates more performant code Is it a license thing or a technical driven issue?

quietbritishjim 8y ago
As I understand it, one benefit of LLVM is that it has a cleaner backend interface, so it is easier to create a new compiler by using LLVM as your backend rather than GCC's backend. (In case it is not clear, just to be explicit: LLVM corresponds to only the backend part of GCC. Clang+LLVM correspond to the whole GCC C++ compiler.)
pjmlp 8y ago
License mostly. Given the amount of BSD deployments, I bet if Linux never happened, I would still be using Solaris, Aix, HP-UX, ..., as I don't imagine UNIX vendors would have been so generous with the *BSDs.
hak8or 8y ago
More performant I am not sure. Would have to see specific benchmarks comparing and the assembly for the newest gcc and newest clang. The reaosn why I vastly prefer clang is for three main reasons. Firstly, clang and llvm are written in c++ so it's much easier for me to work with. Secondly, it has proper documentation on how to, for example, add new optimization passes or adding a new instruction. This includes tons of talks and presentations on doing this live. Thirdly, the tooling for it is great, such as clangd, llc, lld, clanggtidy, etc. Gcc seems to have none of this. Oh, and almost forgot, most importantly llvm + clang is actually open source (more open) via a MIT license instead of gpl.
- fs111 8y ago
  > Firstly, clang and llvm are written in c++ so it's much easier for me to work with. Why is the implementation language important to you as a user?
  - endorphone 8y ago
    Their interest seems to be primarily in alter the toolchain itself. To make this a multi-use comment, I'll also reply to GP and say that in every single case where I've benchmarked time sensitive code, GCC has generated faster, tighter code. I still primarily use clang for other reasons, but saying that GCC is more performant seems to be entirely valid.
  - maxerickson 8y ago
    The answer is in the paragraph you quoted from. "work with" includes extending the implementation.
- callinyouin 8y ago
  I was with you until the end of your comment: > llvm + clang is actually open source (more open) via a MIT license instead of gpl How is a license that allows someone or some corporation to take some code, add to it, and make those additions proprietary "more open" than a license that specifically disallows that type of scenario? The GPL ensures that derived code stays open while MIT does not. In my eyes, that's "actually open source". I can see the argument that licenses like MIT allow consumers of some piece of code more freedom to do as they please, but that hardly makes it more open.
  - protomyth 8y ago
    How is a license that allows someone or some corporation to take some code, add to it, and make those additions proprietary "more open" than a license that specifically disallows that type of scenario? This gets argued all the time. What the corporation did was freedom for them not the code. GPL protects the code, MIT/BSD protects the people. Depending on your definition of "freedom" you will prefer one over the other.
bluescarni 8y ago
I would not be so sure about the declining importance of GCC. GCC has caught up a lot with clang in the last few years, from the quality of error messages, to standard compliance, compilation times, tooling, sanitizers, etc. IME GCC tends to produce faster code in practice, even if clang is often able to out-smart GCC in many areas (e.g., IIRC heap elision was first introduced in clang). GCC has a huge amount of inertia behind it, it's still the only compiler officially supported for compiling the Linux kernel, and, as long as the GCC developers don't stop improving it, it will be difficult for clang to take its role as "default" compiler, at least in Linux environments. I use them both daily and I am really happy that we have the possibility of freely choosing between two such amazing projects. It would be a step backwards if one of them ended up fading away.
- nwellnhof 8y ago
  Compilation times? I thought that compliling with GCC has always been faster than with clang, at least in the general case.
  - ebikelaw 8y ago
    For C++ in my experience clang is much faster, especially for plain (unoptimized) builds.
    - dman 8y ago
      That has reversed in the last few releases of clang for my codebase.
      - ebikelaw 8y ago
        Because gcc got faster or because clang got slower?
        Kranar 8y ago
        Because clang got a LOT slower and GCC got a bit faster. clang used to be incredibly fast and used little memory consumption, but recent versions have seen the compiler regress in both areas. On the other hand clang does a lot more now than it used to so it's somewhat justified. My own experience with a substantial codebase (1+ million lines of code) is MSVC uses the least amount of RAM, followed by clang and then GCC. For performance in terms of compiling/linking it's GCC/clang tied and then MSVC from fastest to slowest.
readittwice 8y ago
I guess both. GCC is very good for compiling C/C++ to machine code. But if you want to write a new language and reuse an existing compiler pipeline (Rust, Swift,..) or write a new tool based on a C++-parser (clang-format, clang-tiny, clangd,...) then LLVM is the way to go. LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end. GCC could have done that too: they didn't for political reasons. Why? Someone could have used GCC's C++ front-end for its proprietary compilation pipeline. Today this is nearly impossible to change in GCC. There are also some other advantages for LLVM I like: it supports multiple architectures in a single binary. With GCC I need to compile the compiler either for x64 or arm but not both. GCC is still great but it's not surprising that LLVM is so successful.
- baq 8y ago
  you're of course right except the OP asked about clang and not llvm. clang frontend could generate postprocessed c and pass it into gcc for whatever that's worth.
  - jjuhl 8y ago
    The reverse has actually been done: https://dragonegg.llvm.org https://dragonegg.llvm.org
- admax88q 8y ago
  > LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end. You're implying that GCC doesn't have a separation between language front-end and compilation back-end, but that's not true. GCC has a consistent internal representation known as GENERIC where the front-ends and back-ends meet just like LLVM.
  - monocasa 8y ago
    And GIMPLE... and RTL... And there's three separate forms of GIMPLE while you're at it. It's way easier to work with LLVM IR.
  - 8y ago
tbrock 8y ago
As someone who used to write c++ these are the reasons clang was great for development: - compiles faster - better error messages - tooling (clangformat) is great When it came time to cut a release binary you could always also build with gcc
- ebikelaw 8y ago
  This is what I do. I use clang for everything except the final release. I get clang's speed and superior error messages while I'm editing code, and I get the very slightly, but measurably faster code generated by GCC.
- HelloNurse 8y ago
  I've always used gcc on all platforms for C and C++, but since last year I also use clangformat. On the other hand, the effort of learning clang options, error messages and paths in order to have two compilers available can wait indefinitely until I really need a second opinion about some compilation error; so far it hasn't happened.
  - ebikelaw 8y ago
    You could build with bazel, which ships compiler configs for clang and gcc on linux (among other combinations) in its "CROSSTOOL"[1] file. Then it's trivial to switch compilers with one argument. This feature is a result of Google's years-long support of both GCC and clang for its own build, test, and release. $ bazel build --compiler=my_favorite_compiler //my/fine:program 1: https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain https://github.com/bazelbuild/bazel/wiki/Building-with-a-cus...
    - HelloNurse 8y ago
      Sorry, I lost you at "bazel". Do you believe constructing clang command lines in addition to gcc command lines is harder than setting up a particularly complex build tool like Bazel? Not to mention that it doesn't appear to support GCC and Clang on Windows.
simias 8y ago
Be wary of the optical illusion of the hype cycle, if you base yourself on HN's frontpage you'd think that Rust is more important than C++. In my experience GCC is still the default C and C++ compiler on Linux in most of the industry. If it ain't broke, why change it? Even though I still use GCC to build by C code I'm very happy that LLVM exists, it brought some new blood and much needed competition to the FLOSS compiler scene. It also gave a better architecture to build on if you want to create a new language, it's great that a language like Rust for instance can generate such good machine code by building on top of the LLVM backend. In the GCC-only days the easiest way to create a new compiled language was to emit C as an intermediary target...
- haeffin 8y ago
  Depends on what your industry is. If you're compiling c++ for mobile, clang is pretty much your only choice for iOS and the default choice for Android ...
  - IshKebab 8y ago
    And the default on OSX.
    - JdeBP 8y ago
      ... and indeed on several of the BSDs. It has been the default compiler in base on FreeBSD since version 10, and FreeBSD is now built with it. There was also a push back around 2014 or so to get much of the ports tree built with it, too. DragonFly BSD has been buildable with clang since around 2014, albeit using clang from packages/ports. In 2017 (release 50) the DragonFly people started work on pulling it into base. OpenBSD switched building on x86/amd64 to clang in 2017 and building on armv7 to clang in 2018. NetBSD has included clang in base but as far as I know does not (yet) build with it by default on any architecture.
      - simias 8y ago
        I only mentioned Linux because I knew that my argument wouldn't work for BSDs! But in my defense the situation, at least originally, was more political than technical (at least as far as FreeBSD was concerned, I don't follow the other BSDs too closely). GCC switching to the GPLv3 was a big no-no for many people in the BSD world. As a result they were at the forefront to port the system to clang since they were stuck with an obsolete GPLv2 GCC version.
IshKebab 8y ago
GCC is still important, but yeah Clang is definitely more popular and gaining popularity. I don't think the performance difference between them is significant, but Clang is much nicer if you want to use it as a library, add a new backend, etc. Basically if you want to do anything other than run it from the command line. Oh also, Clang does cross-compilation in a not totally insane way. I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years.
- gmfawcett 8y ago
  > I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years. Let's hope not. The healthy competition between the two projects has been a huge boon for the OSS community.
- aseipp 8y ago
  > I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years. It will not be, because LLVM does not align with the goals of the FSF and GNU projects. A free compiler under a free license is a pretty central project for them. (Besides that, making predictions 10 years out into the future of software seems meaningless. Saying "this thing might still be around in like 2 decades, or not" is... not particularly noteworthy, nor damning) Plus, I simply see no reason to believe this, even aside from that. If anything, GCC development has gotten far more active and improved greatly in the past few years, with consistently high quality releases, each bringing in major features, and adopting work from Clang, and bringing in their own unique work. It would seem each of these projects has livened up quite a lot over time and are offering higher quality than they ever have before. What reason do you have to believe it will be completely abandoned? Just because there's an alternative available? That never happened with Linux, either...
zeveb 8y ago
I think it really does boil down to the license: Apple absolutely hate copyleft, so they poured money into Clang. It's sad, really — look how old the bash & emacs are in macOS these days. And I really don't think that copyleft would hurt Apple: what compiler technology do they want to keep proprietary?
- tzs 8y ago
  Apple started heavily investing in clang and friends because they wanted a compiler suite that was more modular than gcc and that could be used as a library in other things. They wanted to do things like take chains of filters in Core Image and JIT compile them into a single optimized filter that could target the CPU or the specific GPU in that Mac. They wanted to use the compiler's parser as a library in Xcode to handle things like syntax highlighting. Gcc could not do these things as it was at the time. The different parts were tightly coupled in ways to make it hard to separate things out. People had proposed making it more modular but the gcc devs rejected them, with RMS making it clear that the design was the way it was in order to make it harder for proprietary programs to have ways to use gcc's parts. Apple could have forked gcc and changed it to be more modular, but that would have required a lot of changes and a lot of work, and since it would not be accepted upstream they would probably have to do a lot of work every time there was a significant gcc update. It made much more sense in every way for them to go with clang and LLVM, because those were designed to allow the kind of modular, library use that Apple wanted.
bgongfu 8y ago
Two words, nested functions. They should have been in the C standard a long time ago, solving the same problems without them is a major pain. And even though Clang supports most of the rest of the GCC extensions, they stubbornly refuse to touch nested functions. That and the code of conduct social justice warrior bullshit they've been pulling lately keeps me away from Clang these days.
Panino 8y ago
Among other answers, clang supports -Weverything, which I was using just last night.
jlebar 8y ago
As a compiler hacker, I'll posit that LLVM is far easier to hack on. And of course the licensing makes a huge difference. So in terms of mindshare among people who are doing compilers, it's kind of a no-brainer.
iforgotpassword 8y ago
GCC progress was pretty slow before the rise of clang. Clang introduced many features that werent really on the radar of GCC, like better formatting of error messages, tight integration of tools like thread and address sanitizer, and in some areas even more and better warnings. Meanwhile - at least for a short period - gcc was on this optimization fad where they'd just take any occurrence of UB as a reason to silently eliminate chunks of code and render the whole program useless in some cases. With 4.8 they even broke SPEC 2006. The GCC folks always argued that doing so is legal by the standard, but eventually there was enough backlash that the worst instances of such aggressive optimizations were removed.
- gnufx 8y ago
  The case I know of with SPEC was non-conforming code, not undefined behaviour. You really can't hold gcc responsible for bad code, though there's often a workaround like -fno-aggressive-loop-optimizations/-Wno-aggressive-loop-optimizations in that case. I'm glad GCC optimizes well and takes advantage of language definitions (specifically Fortran's) while being more reliable than ifort which gets lionized for optimization.
  - iforgotpassword 8y ago
    That's not the point. Of course you should write proper code, not do goofy things with pointers etc. But what I don't think was to excuse was that the compiler did this without warnings. And again the GCC folks' reply was "well you can crank up the warnings with -Wwhatever-the-hell". But that's just plain stupid. Any time the compiler removes code because of UB, non-conformance or specific interpretation of ambiguous specs in the C (or whatever) standard, a warning should be emitted by default, because it's pretty much guaranteed that the coder made either a blatant mistake or tried to do stuff that's simply wrong, again either by unawareness or by expecting the compiler to still emit some code that will at least work on their specific platform.
    - gnufx 8y ago
      I always advise turning on all warnings and maybe disabling them selectively, and using any static or dynamic analysis available (and understanding the warnings). Compilation time won't catch a lot of things anyhow, and most people just ignore warnings. It's a matter of judgement whether to issue specific warnings by default, but I don't want the noise from things like intentionally elided code from compile-time constants. In the case of aggressive-loop-optimizations I'd have thought the argument would be whether it should be on by default, or at something like -O2. [On my first workhorse systems, reading past the end of an array, as in the SPEC case, gave a hardware error if you didn't disable that.] Incidentally, ifort turns on (or used to) generally-invalid optimizations without warning, which GCC doesn't, and the first question to ask about user complaints of SEGVs on the systems I support is "ifort?" if only because of an optimzation which is valid but hits typical resource limits.

paulirwin 8y ago

Here are the release notes: https://gcc.gnu.org/gcc-8/changes.html#GCC8.2 https://gcc.gnu.org/gcc-8/changes.html#GCC8.2

majewsky 8y ago
Mods: Can you change the submission to point to this instead?
- sctb 8y ago
  Sure thing. Thanks! Updated from https://gcc.gnu.org/ml/gcc/2018-07/msg00378.html https://gcc.gnu.org/ml/gcc/2018-07/msg00378.html.

thestoicattack 8y ago

> When reporting on mismatching template types, the C++ compiler will now use color to highlight the mismatching parts of the template, and will elide the parameters that are common between two mismatching templates, printing [...] instead I'll be interested to see if [...] can make instantiation error messages a lot smaller. I hope so. Also: > AddressSanitizer integration for std::vector, detecting out-of-range accesses to the unused capacity of a vector.

karrotwaltz 8y ago
The most verbose type of template errors I can think of are instantiation errors with multiple candidates and type deduction failures. In these cases there won't be any elision so it won't help much. I still hope one day we'll see GCC & clang implement some kind of parsable diagnostic output (e.g JSON). Simply folding all the candidates on a UI would be a massive step forward in reading template errors.
- jcelerier 8y ago
  > Simply folding all the candidates on a UI would be a massive step forward in reading template errors. well... that's already what happens if you use an IDE ? That's at least the case on Qt Creator
  - karrotwaltz 8y ago
    I've heard a lot of good about QtCreator lately, from multiple people, I'll give it a try soon. Still, some parsable output would be great for many cases, a CI with diagnostic on a web page for example
- Uberphallus 8y ago
  I'll be happy if the mismatching template types are simply aligned in two lines so it's easy to spot the differences.

shawabawa3 8y ago

Seems like a minor bugfix release, not what special relevance or interest this has

SloopJon 8y ago

Meanwhile, RHEL 7 uses GCC 4.8, which first shipped five years ago. How about the Red Hat Developer Toolset? Is that pretty commonly used, or do most Red Hat users stick with the default packages?

batbomb 8y ago
SCL/devtoolset is common.
misnome 8y ago
Lucky you. We’re stuck on RHEL 6. That’s GCC 4.4. And nobody we knows installs the toolset (I think the target user also needs to have it, because C++ libs?)
- gusmd 8y ago
  Nope, your users need not have the toolset, that's the beauty of it! It creates binaries compatible with any distribution newer than the machine where you are compiling. E.g., if building on CentOS 6.7, anyone on 6.7+ can run your binaries. We also have an application stuck on RHEL 6 because of end-users, and I'm happily using devtoolset-7 which gives me GCC 7.x, and quite a bit of C++17 support :) Edit: My understanding is that it achieves that by statically linking in the "newer" parts of libstdc++.
innot 8y ago
The tool we develop at work has recently moved from RHEL 5 to 6 as the bottomline supported release. For us that meant a switch from GCC 4.8 to 6.3. So it's not that bad. And when we switch to Red Hat 7 in the next 3-4 years we might start using GCC 8 with all those cool new features!

pyler 8y ago

This release also fixes LTO bug with large binaries

bluecalm 8y ago

Is there any significant work done on GCC optimizer these days? Most of the changes in recent releases are about nicer error messages (which I love), sanitizers/UB detection (which I also love), new C++ features support (which I think is waste of brain power and time but well, most people like it) but there is little in optimizer department. From me experience GCC generates by far the fastest code (faster than Intel, Clang and Visual Studio). I realize it's hard to make progress after so many years but I am wondering if there is any promising direction which is researched these days or is it only about small fixes here and there.

rurban 8y ago
There needs to be work done, because for my usecases icc is usually a few percentages faster and newer clang almost twice as fast, with proper constexpr support. It's only memset, memcpy though, so who cares.
- rurban 8y ago
  To the downvoters: This is the benchmark where GCC looses big time to clang: https://github.com/rurban/safeclib/blob/master/tests/perf_memcpy_s.c https://github.com/rurban/safeclib/blob/master/tests/perf_me... My clang compiled memcpy_s is faster than the handoptimized glibc assembler and twice as fast than the GCC version. So with a proper compiler you can get rid of handoptimized unportable optimizations easily. In this case memcpy, but also memset, memmove, memchr, ...
benchaney 8y ago
Optimizer improvements are generally added to major version releases. For example if you look at the 8.1 release it has a number of optimization improvements [0]. Not sure how much focus that is receiving right now though. [0] https://gcc.gnu.org/gcc-8/changes.html https://gcc.gnu.org/gcc-8/changes.html

rurban 8y ago

Tile-Gx is dead? That's sad and a bit early. Afaik MikroTik routers, the fastest routers available, are still selling.

112233 8y ago

Have they added a way to turn off spellcheck suggestions yet? Compiling with newer gcc feels like some monty python skit: #include <stdio.h> int main() { retrun 0; } $ gcc a.c a.c: In function ‘main’: a.c:2:14: error: ‘retrun’ undeclared (first use in this function); did you mean ‘setbuf’? Say gcc, why don't you try 'setbuf' yourself before suggesting it? Ugh...