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.

Comments

“Are you tired of your existing compilers?&r

[93 Escort Wagon]

Isn’t that why people left gcc for clang/llvm in the first place?

Are you tired of your existing compilers?

[jbn-o]

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.

Re:I'm getting the feeling...

[serviscope_minor]

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.

Re:I'm getting the feeling...

[goose-incarnated]

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.