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...

[Anonymous Coward]

The problem with C is that in order to implement any kind of ADT like linked lists, height balanced trees, you have to rewrite every single manipulation function (insert, delete, reorder) for each and every structure required. The only workaround are C+ macro voodoo.

C++ fixes this problem with templates. The people who write the specifications for C++ are just getting round to adding all that theoretical concepts written about back in the 1960's. LLVM is where the action is happening now. Everyone can just design their own language and have it transpiled into native assembly language.

Re:I'm getting the feeling...

[Anonymous Coward]

You've clearly not heard of "container_of()" and the general sphere of intrusive data structures. Get with the times, Win32 gramps -- modern C is quite nice as long as you get over the "we could fuck this void cast up!" anxiety.

Re:I'm getting the feeling...

[Tough Love]

I'm getting the feeling... ...that you are not a practising c++ dev.

Re:I'm getting the feeling...

[Anonymous Coward]

For me, GCC went from being buggy in version 6 to excellent in version 7.

I don't think GCC has lost its luster. It's more GNU that has, and thus everything related to it. And that's because the developer-freedom of the richest corporations has replaced the user-freedom of the freeloaders in the mind of many open-sourcers.

Re:I'm getting the feeling...

[Anonymous Coward]

So much confusion, here about gcc vs llvm. Both can host different language compilers. Nobody transpiles anything (except to non-native bytecode, for those backends that provide it), and assembly language is just another human programming language.

Both of these compilers produce binaries that execute directly on the CPU, with the OS as a referee.

llvm is in fact the trendy compiler for whatever reason. Probably because it comes with XCode on MacOS. But anyone can compile just about anything with either of these two compilers. gcc hasn’t been around for much longer, so it probably supports many more (useless) languages than llvm does.

Re:I'm getting the feeling...

[fred6666]

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.

Re:I'm getting the feeling...

[arglebargle_xiv]

"Are you tired of your existing compilers? Want fresh new language features and better optimizations?"

"Then consider ditching gcc and going with LLVM". Is that how the quote ends?

I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

Re:I'm getting the feeling...

[religionofpeas]

Why don't you stick to one release that works ?

Re:I'm getting the feeling...

[goose-incarnated]

"Are you tired of your existing compilers? Want fresh new language features and better optimizations?"

"Then consider ditching gcc and going with LLVM". Is that how the quote ends?

I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

I'm calling you a liar on all of those. The biggest difference is that LLVM is trendy and GCC is not.

very single new release brings more code-generation bugs that we have to work around in our product,

Example? (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).

Re:I'm getting the feeling...

[Anonymous Coward]

Intrusive data structures create massive coupling and reduce abstraction; not acceptable.

Re:I'm getting the feeling...

[OolimPhon]

I can't wait for that festing pile of bloat and compiler bugs to finally die, I really can't. Every single new release brings more code-generation bugs that we have to work around in our product, we're slowly working away at The Mgt. to get them to simply require LLVM or some other compiler that doesn't break things on every release, and whose maintainers will actually respond to bug reports rather than closing them all with WONTFIX, "if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

Wait, what? Has gcc been taken over by Poettering, now?

Re:I'm getting the feeling...

[serviscope_minor]

"if you squint at the spec from just the right angle and use your imagination then this showstopper bug is actually permitted".

IOW you're writing noncompliant code and blaming it on compiler bugs.

All compilers do that whole "squint at the spec from the right angle" because that's how optimizers work. You put in the rules of the spec and the code into a theorem prover and it crunches on it to figure out dead code, aliasing, constants and so on and so forth.

No one's feeding in perverse interpretations of conflicting rules just to fuck with you. A theorem prover doesn't have human intelligence to decide on the sensibleness of various rules. It crunches blindly, quickly and stupidly.

Re:I'm getting the feeling...

[arglebargle_xiv]

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.

Re:I'm getting the feeling...

[arglebargle_xiv]

IOW you're writing noncompliant code and blaming it on compiler bugs.

You're a gcc maintainer I assume? That's one of their main comebacks, "your code is noncompliant and it's not our compiler that's broken". 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?

Oh, right, but it's noncompliant code, not a gcc bug. Closed, WONTFIX.

Re:I'm getting the feeling...

[religionofpeas]

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.

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.

Re:I'm getting the feeling...

[serviscope_minor]

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?

Re:I'm getting the feeling...

[Anonymous Coward]

I work on microprocessors. I looked into using LLVM as a replacement development toolchain and scrapping our existing GCC implementation. LLVM is a nightmare to extend. Its documentation is horribly out of date. The only logical answer I could find is that there is a lot of tribal knowledge and dev support time is focused on big customers like Apple.

GCC is poorly designed but people still seem to think it's a better extension target than LLVM. It's a shame too since LLVM was supposed to be the framework that would make things easier.

Re:I'm getting the feeling...

[Ed Avis]

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.

Re: I'm getting the feeling...

[Anonymous Coward]

GCC's problem is its tyrannical licensing. LLVM is licensed under truly free licenses.

Re: I'm getting the feeling...

[Anonymous Coward]

> GCC's problem is its tyrannical licensing.

Yeah, that evil GPL... tyrannically insisting that you don't take other people's work and sell it as if it were your own...

Re: I'm getting the feeling...

[Anonymous Coward]

If you truly support freedom and the free use of source code, then you shouldn't care at all how other people choose to use code that you wrote. Conversely, if you do care about how people use code you wrote, and especially if you want to dictate how they can or can't use it, then you don't give a fuck about freedom, and you shouldn't claim that you do.

Re: I'm getting the feeling...

[Anonymous Coward]

Bull. Shit.

You're just pissed off because you want to use someone else's work but don't like having to share your derived work with others. So you bitch and moan about 'freedom' as if the authors owe you something (actually EVERYTHING) out of pure generosity - rather than a desire to help the community as a whole.

"Wahh! They won't let me use their code however I want!"

Tough shit. You don't get to dictate how other people should license THEIR code. Write your own fucking code.

Re: I'm getting the feeling...

[Anonymous Coward]

...unless you are mainland Chinese

Re:I'm getting the feeling...

[JesseMcDonald]

emit a diagnostic telling the programmer to apply that optimization in the source code

It usually isn't that simple. The obvious source-level optimizations you're describing are relatively rare; the ones which lead to major size and performance improvements come about when you combine generic code in inlined functions and macros—often from distinct source modules, perhaps even different projects—with the results of prior optimizations. To apply these optimizations at the source level you would need to specialize the definitions for each use case.

Re:I'm getting the feeling...

[tlhIngan]

... 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.

No, everyone moved to LLVM because for a long time, GCC development basically stalled. It was "good enough" and everyone put up with it. DIdn't like it, just put up with it.

Then LLVM came about and that spurred on a flurry of development - it was modern, it was complete, it was useful. There were clear advantages at the time to using LLVM - the compiler gave better error messages and better warnings. And it started supporting modern language features.

This forced the GCC developers to kick up development because GCC was getting rather tired and lacking. This has resulted in GCC improving in leaps and bounds and becoming far less crusty and more modern.

For a long time everyone stuck with GCC 2.95 for everything as it generally worked and was the stable version for many platforms and architectures. The past decade with LLVM has brought so much more to the table and GCC was forced to adapt and proceed beyond 2.95 and produce releases that made significant improvements.

I'd say what happened was LLVM exposed just how old and tired GCC was (something everyone knew but couldn't spur development on) and GCC was forced to shape up. It still has issues, but at least it's up to date these days.

Re: I'm getting the feeling...

[Anonymous Coward]

GPL doesn't control how you use the code. The license specifically says you can use it for any purpose.

And no, distribution is not 'use' before you come back with that lame argument.

Here lies C++, killed by feature creep

[Anonymous Coward]

Recent features: [=, this] as a lambda capture, Template parameter lists on lambdas, three-way comparison using the "spaceship operator", operator

C++ had Frankenstein's Monster syndrome back when STL started, and the generated templates were near impossible to debug. K&R complained C had too many operators. Here they are adding more and more. Step back from the keyboard and let the language be.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

It's just a programming language. C++ was never simple and lightweight to begin with, adding features people want isn't going to suddenly change it into something over complicated.

C# and Java, to name but two, are alternatives developed in response to C++'s complexities. They're both viable languages.

C++ may fade in the end but it won't be because it's complex. Rather it'll be because it's still easy to write unsafe code, and I don't know much longer that's something that'll be tolerated by the development community. You're already seeing this with Firefox, as it migrates to Rust.

But for those who want C++, adding features isn't a problem. And some of the things you mention actually sound useful.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

Firefox is the only browser that does native MathML. I wish other browsers would pick that up. More importantly I wish eReaders like Kindle and Nook would pick that up. Math and Scientific books suck on the Kindle and Nook.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

I don't know what standard is used by wikipedia but I wish it worked with javascript disabled.

Re:Here lies C++, killed by feature creep

[slew]

The value proposition of 'C' was that you could efficiently program near the metal.

Instruction sets and micro-architectures co-evolved with 'C' along those dimensions of efficiency. 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 (using these kind of idioms, even a memory/perf constrained compiler with limited optimization capabilities could get close to metal performance). As compiler technology advanced and people wanted to write higher level code, C (and C++) continued to have these operator features as boat anchor legacy.

STL and templates basically were an idea to bring generic programming concepts to C. Initially implemented by the c-front pre-processor, initial implementations were forced to live with the limitation of available primitive linker and debugger capabilities which were created for C and other languages w/o these new capabilities. The early problems with templates stems mostly from practical implementations having legacy linkers and debuggers as boat anchors.

The truth is that efficiently implementing the programming idioms of the day is important for any language to remain relevant. Because of legacy, retro-fitting new idioms into older frameworks is sometimes painful, but it the easy way to allow you to incrementally use new features whilst still using old code bases.

** I believe Thompson put those extra operators into 'B' with Ritchie's approval, so maybe it was Kernighan who complained about too many operators and got rid of B's comparison assignment operators (e.g., '=' and '=>=') in 'C'

Re:Here lies C++, killed by feature creep

[religionofpeas]

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.

Re:Here lies C++, killed by feature creep

[sjames]

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).

Of course these days, optimization is better and the different forms will produce the same instructions.

Re:Here lies C++, killed by feature creep

[religionofpeas]

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.

Re:Here lies C++, killed by feature creep

[serviscope_minor]

Recent features: [=, this] as a lambda capture, Template parameter lists on lambdas,

What's wrong with those? The parameter lists just make lambdas work and act more like all other functions rather than being a special case.

Here they are adding more and more. Step back from the keyboard and let the language be.

No thanks. The world moves on. It turns out there have been developments in programming since the early 1970s and I'd rather be able to use them rather than micromanage eveyr aspect of the compiler.

The main thing C has going for it for general purpose code these days is the absurd degree of fetishisation it has in the open source community.

Re:Here lies C++, killed by feature creep

[sjames]

It has been decades, but IIRC, MSC and Borland in their earlier versions (and so, also Lattice C).

Keep in mind, this was when you could significantly speed up a program by choosing well what variables to declare as register since the compiler didn't know.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

C++ may fade in the end but it won't be because it's complex. Rather it'll be because it's still easy to write unsafe code

Those are more or less the same.

Go and read one of the standards dealing with writing safety critical code.
First they rule out any higher level "safe" languages simply because they aren't safe.
A buffer overflow is one thing, they can cause bad things to happen, but you really don't want your ABS to throw an exception or start the garbage collector at the wrong time.

The next step is to limit C down to its bare bones. Not because the complexity and features by themselves are buggy but because they make the code less readable.
Sure, abstractions might in some cases make the code more readable, but they also makes it a lot harder to verify that the code actually does what it is supposed to do.
Most bugs aren't really from problems with the compilers. Most bugs comes from the programmer not realizing what the code does in all cases.
Higher level languages doesn't help in that regard and more ways to write the same code doesn't help either.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

The ++ operator isn't really meant for incrementing with one either. It is meant to step pointers to the next element regardless of element size.
It works well with many processors that can post increment address registers based on operand size.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

can you name one

Whitesmiths compilers did that. I recall back in the early 90's writing code for embedded MC68000 chips and consciously choosing ++a over a = a+1 because it generated an INC instruction versus a MOV/ADD pair because I needed to keep the byte count of the code as small as possible. We also didn't use the printf functions to avoid linking in a floating point library that we didn't need anywhere else.

Re:Here lies C++, killed by feature creep

[Anonymous Coward]

Dennis Ritchie had some interesting reflection:

"Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."

https://www.bell-labs.com/usr/dmr/www/chist.html

Re:Here lies C++, killed by feature creep

[peppepz]

A buffer overflow is one thing, they can cause bad things to happen, but you really don't want your ABS to throw an exception or start the garbage collector at the wrong time.

And what would you want it to do? Return a nonsensical result and keep the program going on without detecting the fault? In the past many safety-critical applications were coded in Ada because of the language's safety-oriented design, which included exceptions.

Re:Here lies C++, killed by feature creep

[K. S. Kyosuke]

Template parameter lists on lambdas

Ah, the M:N feature interaction problem... And the reason I really like simple languages.

Re:Here lies C++, killed by feature creep

[K. S. Kyosuke]

TeX isn't semantic - hell, it's not just that, it isn't even parseable without a full TeX implementation - and nobody forces you to write MathML by hand.

Re:Here lies C++, killed by feature creep

[K. S. Kyosuke]

Ah, that should have been M:M, obviously.

Future migration from weak C.

[Anonymous Coward]

I did discover a new programming language that may revolutionate the paradigms of the programmation.

In a near future, there will be a migration from weak C to strong C that could be possible in 2 or 3 years.

GCC is overcomplicated to develop the front-end or the back-end.

There are many options:
1. my language + GCC's back-end (Intermediate Representation).
2. my language to generate to C or C++ and later compiled by GCC.
3. my language + own back-end from scratch.

Re:Future migration from weak C.

[Anonymous Coward]

You forgot to say that your language also has hookers and blackjack.

Re: Future migration from weak C.

[Anonymous Coward]

"Strong C" derivatives have been tried many times. Many, many, times. All failed.

The simple fact is, the world will continue to be written in C with higher level languages on top. Forever.

Designated Initializers

[Tough Love]

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.

Re:Designated Initializers

[Anonymous Coward]

What? Are you saying that there's no C++-ish equivalent to struct literals in C++ before '20? And don't give me that init order stuff -- C also does it in indeterminate order if values come from function calls, which lets the compiler do black magic on RISC targets to optimize the call sequencing.

Re:Designated Initializers

[Tough Love]

Comprehension comes from reading.

Re:Designated Initializers

[Anonymous Coward]

The lack of C99-style designated initialisers (or a decent alternative) was my personal pet-peeve of C++. I'm happy to hear this was voted into the standard at last.

It's nice being on the bleeding edge.

[Anonymous Coward]

I run Fedora 28, which has gcc 8 by default. Can confirm, has improvements.

Re:It's nice being on the bleeding edge.

[Anonymous Coward]

Please, daddy. Do it.

modules

[Anonymous Coward]

the only new feature that really matters

“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?

Wrong.

[Gravis Zero]

I'm getting the feeling that gcc has gone "uncool", largely because llvm is where all the hipsters are but also because it's now trying too hard

And here I thought it was because GCC is an unwieldy monster that uses an abundance of proprietary macros, compiler extensions and only recently allowed C++ on a limited basis. Silly me.

Re:Wrong.

[Anonymous Coward]

If you want to make complaints go ahead and make complaints. But please learn English first so the rest of us can actually understand what you meant to say. Looking "proprietary" up in a dictionary would be a good step.

Re:Wrong.

[religionofpeas]

I use gcc every single day, mostly for embedded work, and I'm quite happy with the results. Maybe inside it's an unwieldy monster, but I don't have to look at that, so it doesn't bother me. I even use some the compiler extensions, as they are quite useful for my job.

Fortran 2018

[Anonymous Coward]

*Facepalm*

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:Are you tired of your existing compilers?

[Dog-Cow]

as soon as Apple finds the compiler to be good enough they'll stop their upstream contributions.

So... never?

Re:Are you tired of your existing compilers?

[93 Escort Wagon]

In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

Okay, and how about FreeBSD and OpenBSD - and, since you called out Apple, how about Android? They've all moved to Clang.

I guess not everyone is sufficiently adherent to The One True Faith.

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.

Re:Are you tired of your existing compilers?

[arglebargle_xiv]

In the case of Apple and Qualcomm, they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

I prefer a compiler that generates efficient, error-free code, and that's it. I'll leave focusing on the ideological wankery to the SJWs.

Re:Are you tired of your existing compilers?

[sjames]

That "ideological wankery" is why so many kids can afford access to mainstream professional development tools today. The kids in the '70s and early '80s didn't use BASIC because they thought it was the best choice, they did it because a decent professional grade C compiler cost hundreds of dollars (close to a thousand in today's dollars)

What you call wankery, I call simple practicality. Why would I want to tie the future of my software to the "good will" of a proprietary vendor?

Re:Are you tired of your existing compilers?

[religionofpeas]

The kids in the '70s and early '80s didn't use BASIC because they thought it was the best choice, they did it because a decent professional grade C compiler cost hundreds of dollars (close to a thousand in today's dollars)

I thought it was because I was running a 6502 with 12kB of memory and cassette tapes.

Re:Are you tired of your existing compilers?

[tlhIngan]

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.

Well, several reasons. First was GPLv3 which most companies are extremely wary of. Apple began investment in LLVM long before GCC went GPLv3 - LLVM was available as a limited functionality toolchain since OS X 10.3 or so. I think Apple fully switched a year or two after GCC made the switch.

The second reason is code duplication - GCC is intentionally hard to modularize - generally decided as a way to enforce the GPL. Apple and XCode needed modularity so they could neat tricks like in-place compilation (the compiler regenerates the code as you fix the error), as well as syntax error highlighting (it finds an error as you make it).

Since Apple was effectively rewriting a front end compiler for these functions, they contributed that to make CLang, as well as using bits and pieces of LLVM since it was much easier to integrate.

One side effect is the standardization of compilers - before LLVM, everyone had their own compilers, all with varying stages of compatibility for code. Nowadays, it seems everyone has abandoned their own compilers and standardized on LLVM, with interesting effects. It's done interesting things including having final compilation postponed until runtime where you can take the IR bytecode and then use it to target either the main CPU, GPU, DSP or other accelerator at runtime.

Another thing is drivers often need to compile code at runtime. Instead of everyone having crappy compilers (and having to be driver-version-dependent because some versions come with lame compilers), you have drivers with generally good compilers.

Toolchain quality has gone up significantly the past few years

Re:Are you tired of your existing compilers?

[Anonymous Coward]

they apparently prefer a compiler that will let them distribute a proprietary (non-free, user-subjugating) derivative.

Worse clang can be integrated with an IDE ( refactoring, syntax highlighting, autocompletion, ... ), somthing gcc can't and never will support. IDEs that offer these features for C++ either have to rely on incomplete hacks or simply use functionality provided by clang. Last time someone tried to write refactoring with official gcc support for emacs he got stalled by RMS for over a year before it was effectively killed - RMS "planned" to look into a possible solution, none ever surfaced.

Re:Are you tired of your existing compilers?

[sjames]

That's why you did it, but the Apple ][, PET, VIC-20, and C64 could have managed it if expanded from the base models. Certainly, the old IBM-PC (or the many clones) could handle a C compiler, but it was a few years before anything like a useful proprietary C compiler became somewhat affordable.

Keep in mind, the PDP-7 wasn't that much more capable.

Re:Are you tired of your existing compilers?

[Anonymous Coward]

Ah, Turbo C++ with TurboVision for $100 back in the 90's.

Re:Are you tired of your existing compilers?

[Anonymous Coward]

I thought it was because most kids in the '70s and early '80s had never heard of 'C.'

I only heard of Pascal when Apple introduced their language card in 1979. I didn't hear of 'C' until several years later when some magazine (Byte, I think?) profiled the language.

Re:Are you tired of your existing compilers?

[Anonymous Coward]

Minor nit: it might have been technically possible to expand a VIC-20 from it's less than "3563 bytes free" but who in their right mind would have taken a soldering iron to it when a C64 was only somewhat more expensive?

Also, Borland (in the late 80s) had eval copies of Turbo C++ (read: available for poor students like me) available for $50. I can confirm it worked just fine on the PCjr my family owned with its two 5 1/4" floppy drives and 256k of RAM.

Re:Are you tired of your existing compilers?

[sjames]

The Vic-20 came out before there was a C64. So some people did expand their existing Vic. I also saw one with the ROMs swapped out for a FORTH system.

I said early '80s exactly because Borland did make having a C compiler more affordable. Of course, at that time it was seen as more of a beginner's compiler than pro grade (even if it was in many ways superior to MSC).

Re:Are you tired of your existing compilers?

[Anonymous Coward]

Solving plugin issues in GCC is like solving messaging system in HURD, it won't be addressed until/that make the projects become irrelevant. Coincident? I don't think so.

Originally Fortran 2015...

[slew]

They are running a little late...

Re:Originally Fortran 2015...

[Anonymous Coward]

Better late than never. Personally I find gfortran to be rather nice modern Fortran compiler, but the new parallel functionality (co-array stuff) can just as well be implemented using the industry standard MPI.
The modern Fortran language is actually very nice. The syntax is simple and mathematical and scientific coding is easy to do. Things can be done in OO style. I like.

Maybe not

[Kormoran]

"From: Jakub Jelinek : GCC 8.1 Released

Some code that compiled successfully with older GCC versions might require
source changes"

OK I'll stick to my version, I think...

Re:Maybe not

[rl117]

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.

auto increment and decrement...

[Anonymous Coward]

really shine in pointer arithmetic, since many instruction sets have auto-incrrement and auto-decrement
addressing modes. I.e get what R1 points to, then increment R1 by 1,2 or 4 for .b,.w,.l