
GCC 9.3 - lelf
https://lists.gnu.org/archive/html/info-gnu/2020-03/msg00006.html
======
mratsim
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](https://gcc.godbolt.org/z/2h768y)

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

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

------
gilnaa
List of bugs fixed in 9.3:

[https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED...](https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.3)

~~~
joosters
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

~~~
garenp
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](https://gcc.gnu.org/gcc-9/changes.html)

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

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

~~~
smabie
[http://www.slackware.com/changelog/current.php?cpu=x86_64](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.

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

------
blackandblue
a lot of fortran fixes!

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

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

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

~~~
MaxBarraclough
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...](https://www.phoronix.com/scan.php?page=article&item=gcc9-clang8-hedt&num=3)

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

