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

I'm getting the feeling...

[Anonymous Coward]

... that gcc has gone "uncool", largely because llvm is where all the hipsters are but also because it's now trying too hard, and worse, that C++ is trying to prove something, only to end up like some sort of perl or something. This doesn't seem to be a recipe for success to me.

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.

Re:Are you tired of your existing compilers?

[jbn-o]

Your namecalling notwithstanding, Brad Kuhn has already covered this as well and there's nothing particularly special about the examples you list. Apple certainly stands out because of Apple's irrational hatred of being a GPL licensee (which dates back to how NeXT treated NeXT OS users with their Objective-C additions to GCC, referenced in Copyleft: Pragmatic Idealism). Kuhn pointed out something that might be the case now: there are non-free add-ons for that compiler. As these add-ons gain popularity developers become dependent on their functionality. Kuhn has said that there could come a time when such dependence means that practical use of that compiler will almost require using these non-free add-ons as well. This means spreading more software non-freedom to more computer users. I imagine that won't be much of a problem for any OS that accepts non-free software (say by distributing non-free kernel modules, or encouraging users to install non-free applications) because such choices indicate they've already chosen to become dependent on non-free software.