GCC 9.3(lists.gnu.org)

112 pointsby lelfvor 6 Jahren56 comments

lists.gnu.org

https://lists.gnu.org/archive/html/info-gnu/2020-03/msg00006.html

57 comments

mratsimvor 6 Jahren

I hope one day we will be able to use C to implement efficient multiprecision arithmetic.

GCC codegen for add with carry, even with the addcarry_u64 intrinsics is a disgrace[1].

[1]: https://gcc.godbolt.org/z/2h768y

BubRossvor 6 Jahren

Seems like the type of thing that could be done with C++, expression templates and asm. Maybe even an expression JIT.

MaxBarracloughvor 6 Jahren

mratsim is right that the solution is to just improve the code-generation for the existing intrinsics. Given that the intrinsics already exist in GCC, optimising the code is the right way to handle it. (Intrinsics still have their usual obvious downsides, mainly non-portability.)

JIT seems a poor fit. JIT makes the most sense where the desired program behaviour is variable. Intrinsics fit perfectly here.

Templates don't help solve the problem, but they might be a good way to expose the functionality to C++ programmers.

Assembly is how you'd solve the problem efficiently in the absence of a compiler intrinsic. Intrinsics should be able to do an even better job.

unlinked_dllvor 6 Jahren

Definitely can be done with a little bit of impedance losses depending on what you care about. I once wrote it for block floating point on hardware that didn't support it. You can use custom literal suffixes too.

gilnaavor 6 Jahren

List of bugs fixed in 9.3:

https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...

joostersvor 6 Jahren

Are there changelogs for gcc point releases? gcc.gnu.org has a 'changes' link but it is actually a 8->9 changelog, rather than 9.2->9.3

garenpvor 6 Jahren

Yup. If you look at the end of the 'changes' link[1] you'll see individual bugzilla links for issues (or PRs as they call them) that were resolved in a given point release.

[1] https://gcc.gnu.org/gcc-9/changes.html

not2bvor 6 Jahren

The ChangeLog file is in the source code distribution. But the point releases mainly have a large number of bug fixes, there are no new features.

enriqutovor 6 Jahren

I wonder which of my "pet" virtual machines will hit it first: slackware or voidlinux ?

asymptotically2vor 6 Jahren

It landed in the Gentoo tree 12 hours ago :D

Aaronstotlevor 6 Jahren

Out of curiosity, what do you do with either of these "pet" machines? I always have an idea to make a virtual machine cluster, or something similar, but I haven't taken the plunge yet.

enriqutovor 6 Jahren

I find them very useful for testing codes, as a sort of rapid-response travis. I run a script that pulls any new modification into each of my five "pets" (openbsd, slackware, freebsd, voidlinux+musl, dragonflybsd) and runs the tests. Since the systems are so different, it is very easy to break something. Since you notice it immediately (and not after waiting 1 minute for the travis answer) you develop a sense for avoiding non-portable things.

azinman2vor 6 Jahren

Slackware... they still active? No new stable builds in 4 years but seems to get security updates curiously. Their store leads to an error page in what looks like Chinese, confusingly.

charlesdanielsvor 6 Jahren

Slackware still lives. I'm running it on my daily driver right now. I actually just started using Slackware a few months ago too, so it's gained at least one new user in the last 12 months.

Many updates are pushed to https://slackbuilds.org/ every week.

Things definitely seem to move slower than on other OSes, but I much prefer it that way. I still run a supported LTS kernel and a supported LTS Firefox release; as long as security updates keep coming I don't feel the need to upgrade to newer software by and large.

smhendersonvor 6 Jahren

The store thing is a sad state of affairs. Basically, as I understand it, the store was not run by Patrick Volkerding but by a third party that agreed to share profits with him from sales of Slackware branded merchandise. Patrick states that after a few years and much review he was basically being ripped off by them and withdrew permission for them to continue.

Although helped by many volunteers Slackware is mostly a one man show and Patrick's income from the project was basically drawing down to zero. It seems to be a long, drawn out affair and I'm trying to come across as neutral here as I'm sure I don't have all the information. But I'll admit some bias as I started my life with Linux using Slackware from a CD that came with a book about Linux, I think in 1994, maybe early 1995. I switched to more mainstream distros at some point based on me using them at various jobs but always liked the idea of Slackware (the most BSD like Linux!).

And I'm posting this from a laptop running -current. Yes, 15 has been a long time coming but Patrick continues to publish updates and the Slackware Security mailing list is alive and active.

I'm off topic here so I'll wind this up with a note that the GCC package for Slackware Current is gcc-9.2.0-i586-4.txz. So I'm sure 9.3 will be coming along soon, though not as quickly as with some other distros.

For those interested in more about the store I found the most relevant information here[1] when I last went looking for a way to contribute money to the project (i.e. to Patrick).

[1]https://www.linuxquestions.org/questions/slackware-14/donati...

edit: grammar

smabievor 6 Jahren

http://www.slackware.com/changelog/current.php?cpu=x86_64

The changelog seems to be, uhh, changing, so that's good I guess. I'm not sure they have many users left though.

smhendersonvor 6 Jahren

We're around and it gained a bit more attention during a recent system wide change to many, more mainstream, distros that I'm sure most people here on HN don't really want to talk about (again).

I like it because it leans more closely to traditional BSD systems than System V variants like Red Hat.

smhendersonvor 6 Jahren

Their both on 9.2 in their "current", rolling releases so I guess the race is on!

[deleted]vor 6 Jahren

blackandbluevor 6 Jahren

a lot of fortran fixes!

smabievor 6 Jahren

Honest question: what value does GCC have in 2020? It seems like llvm is the better designed compiler, more commercial support, more permissive license, etc. Pretty much everyone designing new languages today is using LLVM for backend codegen; and the people who aren't sure as hell are not using GCC.

brandmeyervor 6 Jahren

Here's a key paragraph from Anandtech's recent article on ARM in AWS:

> Overall, I checked three different compiler setups: A freshly compiled GCC 9.2.0 release, Arm’s Allinea Studio Compiler 20 package which comes with both Arm’s closed source LLVM and Flang variants as well as a pre-compiled version of GCC 9.2.0, and Marvell’s branch of LLVM and Flang.

Note the phrases "ARM's closed source LLVM" and "Marvell's branch of LLVM". That's why GCC is still critical. Because LLVM is already suffering from the fragmentation and proprietary forks that BSD has always suffered from.

yjftsjthsd-hvor 6 Jahren

I'm having trouble finding whether this is still true, but for a long time gcc was the only supported option for building Linux (the kernel). I know there's been work to make it build with clang, but it at least used to be that you needed some patches.

Someonevor 6 Jahren

That isn’t true anymore, not even for x86_64 (https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNote...)

yjftsjthsd-hvor 6 Jahren

Oh, excellent:) Thanks for sharing an official source for that.

pengaruvor 6 Jahren

> more permissive license

Not everyone favors a more permissive license.

rnd0vor 6 Jahren

There's permissive and then there's exploitable. People who benefit (financially) from being able use other people's work without contributing their own changes would prefer us to call it "permissive" instead of "exploitive".

It's sad that the movement which originally democratized computing (by placing development tools into the hands of ordinary users) is slowly being changed into a pyramid scheme that fleeces volunteers.

So, to echo other comments in this thread; GCC keeps the corporate BSD crowd honest, and postpones the day when they lock up their code.

nwallinvor 6 Jahren

It produces faster binaries than clang, sometimes significantly so.

ICC produces faster binaries than GCC, but ICC is expensive and GCC is free.

MSVC is garbage.

pjmlpvor 6 Jahren

Desktop and Game developers happen to share a different opinion.

MaxBarracloughvor 6 Jahren

Does ICC have any traction in the gaming world?

pjmlpvor 6 Jahren

It does on Windows shops that care about the ultimate performance optimization on Intel CPUs and vtune integration.

MaxBarracloughvor 6 Jahren

Doesn't that describe all high-budget games?

Would the average Unreal-based game be built with ICC?

pjmlpvor 6 Jahren

Depends on the studio. Here is an overview and some testimonials,

https://software.intel.com/en-us/gamedev/tools

MaxBarracloughvor 6 Jahren

At a glance it seems the answer is No.

Unreal Engine 4 doesn't officially support icc, for instance. Neither does the Source Engine. I believe the same goes for CryEngine.

pjmlpvor 6 Jahren

Going back to my initial reply, I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++.

Specially given the lack of tooling that is only matched by C++ Builder, although I did not refer this point on my original reply.

So if you are reducing the world to just what Unreal, Source and CryEngine officially support, I wonder how many AAA games have been released on Windows using GCC or clang with those engines.

MaxBarracloughvor 6 Jahren

> I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++

Yes, sure. MSVC is garbage clearly isn't right.

I presume (in the absence of any real data of course) that ICC doesn't result in significant performance advantages over MSVC, for games, or it would have been worth these developer's time to support it.

> if you are reducing the world to just what Unreal, Source and CryEngine officially support

It's a reduction sure enough, but I think that's a reasonable set of engines to consider.

> I wonder how many AAA games have been released on Windows using GCC or clang with those engines

I imagine it's none.

According to the (quite possibly stale) official wiki, Source does not support Clang, and only supports GCC for building Linux dedicated servers. [0]

It looks like Unreal Engine supports Clang for Linux builds [1], but for Windows it seems they really only support MSVC, although Clang can be made to work [2][3]

CryEngine supports Clang for Linux builds [4], but not for Windows where it seems to be MSVC-only [5][6]

[0] https://developer.valvesoftware.com/wiki/Compiler_Choices

[1] https://wiki.unrealengine.com/Compiling_For_Linux

[2] https://docs.unrealengine.com/en-US/Programming/Development/...

[3] https://forums.unrealengine.com/development-discussion/engin...

[4] https://docs.cryengine.com/display/SDKDOC4/CRYENGINE+on+Linu...

[5] https://github.com/CRYTEK/CRYENGINE/issues/381

[6] https://docs.cryengine.com/display/CEPROG/Building+the+Engin...

alfalfasproutvor 6 Jahren

It's still the "de facto" compiler on most flavors of Linux and still tends to produce faster binaries in practice than Clang. That gap, however, continues to narrow.

CannoloBlahnikvor 6 Jahren

I always viewed Clang as faster, and perceived GCC as catching up.

MaxBarracloughvor 6 Jahren

As of May 2019, Phoronix showed them being roughly equal, with the winner depending on the application. https://www.phoronix.com/scan.php?page=article&item=gcc9-cla...

We should expect them to both continue to improve. It's not a sure thing that Clang will end up the clear winner.

eMSFvor 6 Jahren

The perception of Apple's Midas Touch has never been dependent on banal things like objective comparisons.

throwaway744678vor 6 Jahren

Clang has faster compilation, but (depending on the actual case) optimized binary built by gcc run faster; as mentioned above, both gaps are narrowing.

mratsimvor 6 Jahren

GCC is bad for anything related to big integer arithmetic or cryptography unfortunately. Something like 20 to 40% slower than Clang.

Example of GCC awful codegen on add with carry: https://gcc.godbolt.org/z/2h768y

gmfawcettvor 6 Jahren

GCC has the same value that LLVM had when it was first released: healthy competition for the market leader. The need to compete with LLVM was the best thing that ever happened to the GCC project. A world with only LLVM could easily lead back to a stagnant monoculture.

Therefore, it's in everyone's selfish interest to promote and use both toolchains.

BiteCode_devvor 6 Jahren

See also:

- firefox and chrome

- ios and android

- mysql and postgres

MaxBarracloughvor 6 Jahren

- AMD and Intel

- C# and Java

More generally of course, healthy competition is good. There are more than 2 serious Java IDEs, for instance.

asveikauvor 6 Jahren

Right now, or last I checked, GCC supports more architectures. So while I realize that the Intel/ARM monoculture (or duoculture?) plus occasional emergence of things like risc-v will continue to absorb the world's new devices, there will probably be niche uses of GCC to target obscure hardware for a long time.

homarpvor 6 Jahren

Competition and less permissive license (the license kind of ensures gcc can not be 'closed' and therefore ensure that llvm's license stays 'more permissive').

geofftvor 6 Jahren

A few things off the top of my head, influenced by both trying to build Rust code for the Linux kernel as a hobby and maintaining compilers in my day job:

- GCC still supports more architectures/platforms than LLVM does. Apart from various rare/obscure/embedded platforms, one notable one (I think) is x86-16: .code16gcc pretty much works, LLVM only kinda supports it.

- GCC has its own plugin interface. If you already have GCC plugins, you probably want to stick with GCC.

- If you have a large legacy codebase that's probably got some UB somewhere because that's the nature of having large codebases written by fallible humans, it's probably less likely that a new versions of the same compiler will misinterpret your intentions than a new compiler would. (But this is a weak argument, since new versions could still change their interpretation/behavior.)

chrisseatonvor 6 Jahren

I think GCC often still outperforms LLVM for many people's workloads. Not sure why that is - haven't we gotten to the point where any missing optimisations can just be added to LLVM? Are some optimisations very hard to add given LLVM's architecture? There must be enough people and companies working on it by now to fix anything?

But if you're really serious about performance presumably you're using Intel.

dahartvor 6 Jahren

> But if you're really serious about performance presumably you're using Intel.

Or a GPU?

chrisseatonvor 6 Jahren

We (as an industry) just don't know how to put some programs onto the GPU yet.

dahartvor 6 Jahren

Agreed, true!

BubRossvor 6 Jahren

Or an FPGA or an ASIC, but this is obviously.in the context of CPUs.

umvivor 6 Jahren

How's LLVM's code coverage performance?

Starting with GCC 9, you can stream gcov straight to stdout in json format, which allowed me to write a multi-core coverage aggregation/analysis tool[1] to replace lcov (and is over 100x faster than lcov, in my case - ymmv):

[1] https://github.com/RPGillespie6/fastcov

touisteurvor 6 Jahren

Aaaah if only I could do this to a runtime defined fd or pipe... Live coverage information! Have to use Intel PT for this but sometimes feels like a big hammer :-)

bluecalmvor 6 Jahren

I use it because it outperforms both Intel and Clang on my code by significant margin. Open MP support in Clang on Windows comes and goes and no one cares (I don't blame them, it's a niche use case but still). I don't see any reason to switch tbh. GCC does the job, is around for much longer, supports more stuff and generates more efficient code (at least in my case).

craigsmansionvor 6 Jahren

At the very least GCC is keeping llvm permissively licensed.

llvm is partly a product of Apple's dislike of copyleft licenses. Without gcc there is no reason for llvm's large proprietary contributors to stick to the "more permissive license" and simply close it down and distribute it as "value added" binaries.