GCC 9.3
lists.gnu.org
lists.gnu.org
GCC codegen for add with carry, even with the addcarry_u64 intrinsics is a disgrace[1].
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.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...
The changelog seems to be, uhh, changing, so that's good I guess. I'm not sure they have many users left though.
I like it because it leans more closely to traditional BSD systems than System V variants like Red Hat.
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.
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
We should expect them to both continue to improve. It's not a sure thing that Clang will end up the clear winner.
Example of GCC awful codegen on add with carry: https://gcc.godbolt.org/z/2h768y
Therefore, it's in everyone's selfish interest to promote and use both toolchains.
- firefox and chrome
- ios and android
- mysql and postgres
- C# and Java
More generally of course, healthy competition is good. There are more than 2 serious Java IDEs, for instance.
- 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.)
But if you're really serious about performance presumably you're using Intel.
Or a GPU?
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):
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.
Not everyone favors a more permissive license.
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.
ICC produces faster binaries than GCC, but ICC is expensive and GCC is free.
MSVC is garbage.
Would the average Unreal-based game be built with ICC?
Unreal Engine 4 doesn't officially support icc, for instance. Neither does the Source Engine. I believe the same goes for CryEngine.
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.
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...
> 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.