Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Does -Ofast still ignore -fno-fast-math ?by dapperdrake
- Noob question - Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? How does it stack in comparison to LLVM?by wg0
- GCC far far far predates LLVM. They do not share code.by kelnos
- > Does gcc use LLVM anywhere under the hood
No
by mshockwave - The other answers (NO!) are correct, but... there was a gcc plug-in to use the llvm backend with gcc. Apple used llvm-gcc (circa 2012; gcc front end, llvm back end) while transitioning from gcc to llvm.by ksherlock
- > Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? No it doesn't use LLVM > How does it stack in comparison to LLVM? Well it support more targets then LLVM and in most cases it generates similar if not better executable.by kouosi
- Let me wikipedia that for you :-) Like people mentioned already, gcc predates LLVM by quite some years, ie. Wikipedia mentions March 22, 1987 for gcc, while LLVM's initial release was 2003.
A big difference between the 2 is also the license. GCC uses the GPL while LLVM uses Apache License, hence the projects don't share code.
by sintax - I tried the unstable sources for a while, in the last ~3 months. I ran into some issues with some programs (could not compile them with recent GCC, but older GCC worked fine), so gcc 15.x works better for me in general (presently) - but from, say, +3000 programs to compile, the vast majority works well, and a few may need patches (which can often be found in LFS/BLFS by the way, they often use sed instructions to fix individual things and then it works usually).
Hopefully they fixed those issues. We all need stability and things-to-work.
by shevy-java - Did you file any bug reports for them?by sintax
- > The so-called "json" format for -fdiagnostics-format= has been removed in this release. Users seeking machine-readable diagnostics from GCC should use SARIF.
But:
> GCC can now output diagnostics in HTML form via -fdiagnostics-add-output=experimental-html
I wonder what drove the decision to remove JSON output and add HTML output?
by kmoser - It looks like SARIF is JSON, with a formal schema. I'm guessing the JSON they used to output used their own, non-standard schema.by rcfox
- I've already been using it for some time (debian sid has a trunk package). it has c++26 reflection, so I already do some magical things with reflection (much better for some cases e.g. for ser-des). I only wish they had a lsp server in their eco-system!by xzstas
- libstd has been giving me issues running gcc 16 binaries on Debian 12 and 13.
- Somehow I never realized that GCC has a very regular release schedule until looking it up just now: https://gcc.gnu.org/develop.htmlby t-3
- It has been that way since people from Cygnus (now RedHat->IBM) reorganized the projectby uyjulian
- Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.by r2vcap
- IIRC, since GCC got covered by GPL3.
It used to be slower and I've spent way too much time working around C++ bugs in GCC 2.95
(The fact that I remember the problematic version is telling :)
by tosti - Large projects have been going to regular scheduled releases for a long time. Until the 90's people thought they could waterfall a large release with all your desired features (and for tiny projects this is still a good idea), but as your projects grow (possibly just to small) you reach a point where someone is always working on a feature that isn't ready yet, so a regular release means you still can support your customers with releases. This forces developers who are unsure they will be ready to have some sort of "disabled this unstable feature" toggle, which is about the best you can do.by bluGill
- I want to point out an implemented feature that people SHOULD be adopting but that I doubt will be picked up:
This is for "std::start_lifetime_as<T>". If you have not heard of this before, it's the non-UB way to type-pun a pointer into a structured type.P2590R2, Explicit lifetime management (PR106658)Nearly all zero-copy code that deals with external I/O buffers looks something like:
With this merged, swap the reinterpret_cast for start_lifetime_as and you're no longer being naughty.std::unique_ptr<char[]> buffer = stream->read(); if (buffer[0] == FOO) processFoo(reinterpret_cast<Foo*>(buffer.get())); // undefined behavior else processBar(reinterpret_cast<Bar*>(buffer.get())); // undefined behaviourby gavinray - You’re allowed to type pun char buffers.
- Your code is not only naughty, it’s also incorrect due to alignment issues.
- Well, ignoring alignment restrictions, it depends on the implementation of read. If it is truly opaque, as far as the compiler is concerned, the kernel (or the network card or whatever) is truly constructing a Foo in that buffer, making the cast perfectly legitimate.
start_lifetime_as is useful when the buffer lifetime is transparent to the compiler and it can mess up aliasing assumptions.
by gpderetta - The cppreference description seems questionable to me:
> Implicitly creates a complete object of type T (whose address is p) and objects nested within it. The value of each created object obj of TriviallyCopyable type U is determined in the same manner as for a call to std::bit_cast<U>(E) except that the storage is not actually accessed, where E is the lvalue of type U denoting obj. Otherwise, the values of such created objects are unspecified.
So T is the complete new object. It contains subobjects, and one of those subobjects has type U. U is initialized as if by bit_cast, and I presume they meant to say that bit_cast casted from the bits already present at the address in question. Since “obj” is mentioned without any definition of any sort, I’ll assume it means something at the correct address.
But what’s E? The page says “E is the lvalue of type U denoting obj,” but obj probably has type char or a similar type, and if it already had type U, there would be no need for bit_cast.
by amluto - There was already a legal way to achieve this that everyone should already have been using (laundering a pointer through a no-op memmove). Using reinterpret_cast here is a bug.
The "start_lifetime_as" facility does one additional thing beyond providing a tidy standard name for the memory laundering incantation. Semantically it doesn't touch the memory whereas the no-op memmove intrinsically does. In practice, this makes little difference, since the compiler could see that the memmove was a no-op and optimized accordingly.