Slashdot Mirror
GCC 8.1 Compiler Introduces Initial C++20 Support (gnu.org)
"Are you tired of your existing compilers? Want fresh new language features and better optimizations?" asks an announcement on the GCC mailing list touting "a major release containing substantial new functionality not available in GCC 7.x or previous GCC releases."
An anonymous reader writes: GNU has released the GCC 8.1 compiler with initial support for the C++20 (C++2A) revision of C++ currently under development. This annual update to the GNU Compiler Collection also comes with many other new features/improvements including but not limited to new ARM CPU support, support for next-generation Intel CPUs, AMD HSA IL, and initial work on Fortran 2018 support.
An anonymous reader writes: GNU has released the GCC 8.1 compiler with initial support for the C++20 (C++2A) revision of C++ currently under development. This annual update to the GNU Compiler Collection also comes with many other new features/improvements including but not limited to new ARM CPU support, support for next-generation Intel CPUs, AMD HSA IL, and initial work on Fortran 2018 support.
Cowabunga! This fixes the single most vexing upward compatibility issue between C and C++, and also a glaring maintainability issue in C++. How sweet that it only took, hmm, two decades to work through the initialization order wankery. Note: gcc has had this since forever, but disabled because the standard org didn't bless it.
When all you have is a hammer, every problem starts to look like a thumb.
Isn’t that why people left gcc for clang/llvm in the first place?
#DeleteChrome
The difference is not the supported languages, but the supported targets.
The embedded systems, toasters, light bulbs of the world are all developed in a language (usually C, and to a lesser extent C++) compiled using GCC or a derivative. But I've never seen a CPU vendor toolchain based on LLVM. I am sure it exists, but the popular ones are still based on GCC. And I've used various platforms from TI, NXP, Microchip, STmicro, Atheros, Broadcom, etc. All based on GCC.
In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative. Brad Kuhn, President of Software Freedom Conservancy, has predicted that as soon as Apple finds the compiler to be good enough they'll stop their upstream contributions.
Digital Citizen
All those extra operators idioms like "+=" and "++" were inherited from its predecessor B** (well actually, adapted from "=+" because of the lexical ambiguity) to match accumulator style instructions common in contemporary instruction sets and to reduce compiler complexity
The first compiler was made on a PDP-7 that didn't even have increment instructions.
The += operator is useful on any platform, simply because it saves you from writing (and reading) the same expression twice.
But for long after that, in simple C compilers, ++ would use INC if it was available while +=1 and a=a+1 would generate multiple instructions or use ADD immediate (and so take more cycles to execute).
Maybe, but that has nothing to do with the reason they are in the language. Also, I doubt many compilers worked that way (can you name one ?). If I had to write a compiler, the first step would be to generate an abstract syntax tree, where a++, a+= 1 and a = a + 1, would all be represented as assign(a, add(a, 1)). Choosing between inc/add would be done at the code generation phase.
I know you don't have an example of consecutive releases with different codegen bugs, but asking at least makes it clear to other readers that you don't know what you are talking about
Gosh, you know a lot about this, don't you? Which version of gcc would you like the bugs for? There's so many of them I'd have to go for a specific version.
Incidentally, this code is built using between thirty and fourty different compilers, depending on how you count them (for example are VC++ 6.0, .NET, and the current Visual Studio counted as the same compiler or not? There are at least three different code bases there). gcc has more code generation bugs than every other compiler combined. That's the sum of thirty to forty compilers that have less bugs combined than gcc. Quite an impressive record. It really is an awful compiler to work with.
gcc is right and every other compiler out there is wrong?
No, gcc is right and the other compilers are right too. Your code is wrong.
C++ is trying to prove something,
About the only thing it's trying to "prove" is that it can move with the times. And it's proving that by doing so. C++98 was awfully long in the tooth by 2011 in that C++11 provided in many cases better, more efficient, shorter, more obvious and cleaner mechanism for doing a lot of common things.
Other things have simply proven incerdibly hard ot get right: concepts has been in the works for 30 years!
This doesn't seem to be a recipe for success to me.
C++ is already successful, but it won't stay that way without work.
SJW n. One who posts facts.
Gosh, you know a lot about this, don't you?
As a matter of fact, I do. A lot more than you, at any rate.
Which version of gcc would you like the bugs for?
You claimed that every new release of GCC brings more codegen bugs:
Every single new release brings more code-generation bugs
So, please, list the codegen bugs you claimed were added between every single release. In other words, for each of the releases listed below, please fill in the new codegen bugs that you found in that release. Since you also claimed that each release has more bugs that the previous one, your list should either grow or contain only bugs that were never fixed in subsequent releases.
So, here is the list; for each one fill in at least one codegen bug that was introduced in that release:
GCC 8.1, GCC 7.3, GCC 5.5, GCC 7.2, GCC 6.4, GCC 7.1, GCC 6.3, GCC 6.2, GCC 4.9.4, GCC 5.4, GCC 6.1, GCC 5.3, GCC 5.2, GCC 4.9.3, GCC 4.8.5, GCC 5.1, GCC 4.8.4, GCC 4.9.2, GCC 4.9.1, GCC 4.7.4, GCC 4.8.3, GCC 4.9.0, GCC 4.8.2, GCC 4.8.1, GCC 4.6.4, GCC 4.7.3, GCC 4.8.0, GCC 4.7.2, GCC 4.5.4, GCC 4.7.1, GCC 4.7.0, GCC 4.4.7, GCC 4.6.3, GCC 4.6.2, GCC 4.6.1, GCC 4.3.6, GCC 4.5.3, GCC 4.4.6, GCC 4.6.0, GCC 4.5.2, GCC 4.4.5, GCC 4.5.1, GCC 4.3.5, GCC 4.4.4, GCC 4.5.0, GCC 4.4.3,
The reason I know that you don't know wht you're talking about is because I actually follow the issues on some of the gcc mailing lists, especially the codegen bugs.
If you don't know what you are doing when using GCC, you're not suddenly going to become competent by switching to LLVM.
You made the claim, now provide the evidence. Consider it an opportunity to show off how well you know your toolchains.
for example are VC++ 6.0, .NET, and the current Visual Studio
Even better, since you're on VC++, let's limit the codegen bugs to those targets that are supported by VC++ too. After all, you can't have been inconvenienced by bugs on a platform you don't use.
I shall be sure to quote this thread back at you every opportunity I get.
I'm a minority race. Save your vitriol for white people.
It's no different to any previous compiler release by any vendor. Any new version may increase the strictness, and if you read the list of extra checks the compiler is doing, they are all entirely reasonable and in most cases only affect buggy code which would misbehave and already needed fixing. Bring on the extra strictness and improve the quality of your codebases, I say.
Good job on ignoring the part where I explained my reasoning.
You're a gcc maintainer I assume?
Nope, I'm a happy user of GCC.
That's one of their main comebacks, "your code is noncompliant and it's not our compiler that's broken".
Yep, and they're correct.
Funny thing is, the thirty to forty other compilers that the same code is built with (see my other comment above) all work fine, it's only gcc that generates invalid code. Odd that, isn't it, that gcc is right and every other compiler out there is wrong?
GCC has better optimizations than the vast majority of those 30-40 compilers. Clang is almost as good and almost as pedantic with the standard now.
Oh, right, but it's noncompliant code, not a gcc bug. Closed, WONTFIX.
Precisely. How the fuck are the GCC maintainers meant to read your mind and know what you meant when you wrote noncompliant code?
SJW n. One who posts facts.
Sometimes I wish that if the optimizer finds something really juicy (like eliminating a dozen lines of code because it can prove they will never be called by assuming that undefined behaviour won't be triggered) it would just refrain from optimizing the code out and instead emit a diagnostic telling the programmer to apply that optimization in the source code. You could then review the code and either say 'gee, the compiler is right, I will delete that whole branch', or 'ouch, that should not be happening... let me find where I am relying on undefined behaviour', or in some cases add an explicit compiler hint to allow the optimizer to take an axe to the code without bothering you further. It would have to be a heuristic, and would produce some false positives (where the optimizer is fine, and should just do its job without chatter), but in the cases it did work it would avoid a lot of acrimony and language-lawyering.
-- Ed Avis ed@membled.com