
GCC 9.1 Released - edelsohn
https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html
======
umvi
For anyone wanting an easy way of trying it out, I recommend grabbing
`zbeekman/nightly-gcc-trunk-docker-image:latest` from Docker Hub, which has
the latest version of GCC pre-built (which, actually looking it it right now
is 10.0) - also, see GitHub landing page for it[1].

I find this to be the easiest way to try out new GCC versions and I actually
use it exclusively for building testing my GCC 9 projects. With just a small
wrapper Dockerfile, you can easy accommodate CMake or any other build
dependencies.

For example, I have one I use for building CMake projects[2] (see README of
same project for example of how to use said docker image).

GCC 9 is great, by the way. One of the best improvements, IMO is that gcov can
now print coverage reports to stdout in JSON format which means you can take
advantage of parallel computing to generate coverage reports fast. The
Dockerfile I linked to in [2] above is a part of a utility I made as a drop-in
replacement for lcov and can generate lcov reports at times up to 100x faster
thanks to GCC 9 improvements.

[1] [https://github.com/zbeekman/nightly-gcc-trunk-docker-
image](https://github.com/zbeekman/nightly-gcc-trunk-docker-image)

[2]
[https://github.com/RPGillespie6/fastcov/blob/master/Dockerfi...](https://github.com/RPGillespie6/fastcov/blob/master/Dockerfile)

~~~
cozzyd
gcc is not particularly hard to build from source either.

~~~
umvi
I had a heck of a time getting it to build under Ubuntu. It was simple under
OpenSUSE however (I followed the instructions both times)

~~~
Keyframe
What problems did you have? It's dead easy.

~~~
umvi
Under Ubuntu 18.04 I followed the instructions here:
[https://gcc.gnu.org/wiki/InstallingGCC](https://gcc.gnu.org/wiki/InstallingGCC)

And everything went well until the `make` step - it just blew up with a
million compiler errors. I did the same thing under OpenSUSE and it built just
fine.

~~~
ComputerGuru
With C++, a million errors are oftentimes one error a million different ways.

~~~
magicalhippo
Flashback... When trying C for the first time, I ported a ~300 line Pascal
program. I had read C syntax for some time, and the program was rather simple
so I felt confident in the job.

After transcribing the ~300 lines I tried to compile for the first time: 3728
errors and warnings...

I read through the code and everything looked correct, so I gave up.

Picked it up again some weeks later. Turned out that I had, by force of habit,
erroneously added a semicolon at the end of macro definition on line 3. Fixing
that it compiled flawlessly.

At the time I was also unaware that I was actually using a C++ compiler,
djgpp, which I'm sure did the error count no favors.

~~~
marktangotango
Ah djgpp, rhide and allegro, that was my gateway drug.

~~~
uzbit
Same here! A while back I found some of my old Allegro games from a high
school CS class (choked back chunks), and with little effort got them to
compile on modern macOS. It was quite nostalgic.

------
diegocg
Related link: GCC 9: Link-time and inter-procedural optimization improvements
[https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-
int...](https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-
procedural.html)

------
qalmakka
I'm building it right now, I'm very curious to try the new features and
especially the improved diagnostics. The competition between Clang and GCC has
been a blessing, they're both better than ever.

------
ausjke
"In this release C++17 support is no longer marked experimental. The C++
front-end implements the full C++17 language (already previous GCC major
version implemented that) and the C++ standard library support is almost
complete. The C++ front-end and library also have numerous further C++2a draft
features [1]. GCC has a new front-end for the D language. GCC 9.1 has newly
partial OpenMP 5.0 support and almost complete OpenACC 2.5 support."

Awesome stuff, happy to see healthy competition between GCC and Clang these
days

------
earenndil
From
[https://gcc.gnu.org/gcc-8/porting_to.html](https://gcc.gnu.org/gcc-8/porting_to.html):

> The alignof operator has been changed to return the minimum alignment
> required by the target ABI, instead of the preferred alignment (consistent
> with _Alignof in C)

> Code which uses alignof to obtain the preferred alignment can use
> __alignof__ instead

So, there's an alignof and an __alignof__ function, which do similar but
subtly different things? That sounds like a recipe for disaster.

~~~
kanox
This is extremely common?

After all, what does __ signal if not "suble difference"?

~~~
comex
GCC extensions in particular tend to support multiple spellings of the same
keyword with different numbers of underscores, which usually do exactly the
same thing. For example, you can write asm, __asm, or __asm__; typeof,
__typeof, or __typeof__; __attribute or __attribute__; etc. The versions with
no underscores only with with a setting of -std that includes GNU extensions,
while the versions with underscores always work (because names starting with
underscores are reserved by the spec).

Even alignof has __alignof and __alignof__ as two spellings of the GNU
variant. But unlike with typeof, for whatever reason, plain "alignof" was
never supported in C as a GNU extension; it only ever worked in C++ mode, as a
standard feature from C++11. That makes it slightly less weird to create a
difference. But only slightly; I'm more familiar with GCC esoterica than most
people and I had no idea "alignof" was C++-exclusive until I looked it up.

------
mhh__
> Support for the D programming language has been added to GCC, implementing
> version 2.076 of the language and run-time library.

Well done Iain Buclaw (and co.)

------
jandrewrogers
It is great to see GCC's C++17 language support coming along and more effort
being put into getting draft standard features in early, as its C++17 support
was quite buggy even a year after the official standard release. C++ language
support is one area where Clang has typically been ahead of GCC.

The competition between the compilers has been great for compiler users.

------
bachmeier
Added in this release: D Language (release 2.076).

------
tntn
Anyone know what happened circa GCC 5 that changed the version number scheme?
It felt like GCC 4 was around forever and now they do whole number increments
every year or so.

~~~
ajross
Fashion. GCC isn't a library, so doesn't have the same kind of hard
compatibility concerns that major version numbers are supposed to reflect.
Other stuff at the same time started doing the same stuff (c.f. Fedora,
Firefox, Chrome), so they did too. Other GNU projects did likewise: Emacs
spent a few decades to get from 19 to 21, and now all of a sudden we're at 26.

~~~
avar

        > Emacs spent a few decades to get from
        > 19 to 21, and now all of a sudden we're
        > at 26.
    

It's just the span between 21 and 22 that took unusually long[1].

The first Emacs 19.* came out in 1993, last 21.* in 2001. So 3 major releases
in 8 years, roughly one every 2.5 years.

The first Emacs 22.* came out in 2007, and 26.* in 2018, so 5 major releases
in 11 years, roughly one every 2.2 years.

Whereas 21.* to 22.* took from 2001 to 2007, or around 6 years. Here's an LWN
article from 2007 covering why it took so long:
[https://lwn.net/Articles/234593/](https://lwn.net/Articles/234593/)

Not everything gets worse as you get older, except perhaps confirmation bias
:)

1\.
[https://en.wikipedia.org/wiki/GNU_Emacs#Release_history](https://en.wikipedia.org/wiki/GNU_Emacs#Release_history)

~~~
ajross
Your subtractions are off by one because you're treating the boundary as a
"release" without accounting for the previous inter-release period. Those
periods reflect, respectively, TWO major releases in 8 years, and FOUR major
releases in 11 years. So things since 22 are about about 50% faster by my
reckoning, which is notable but maybe not as much as as my intuition held.

~~~
avar
If I'm off-by-one I don't know what you're off by claiming "Emacs spent a few
decades to get from 19 to 21" :)

The 19.7 release came out on May 22, 1993, and 21.1 came out on October 20,
2001. That's 8 years, 4 months and 28 days[1], not decades.

Similarly for 22.1 to 26.1, which is a period of 10 years, 11 months and 26
days[2], I took the liberty of rounding that up to 11 years.

Perhaps you're under the mistaken impression that Emacs follows some sort of
sane version numbering scheme, and that before 19.7 there was such a thing as
a 19.6 release, or indeed any other 19.* version, or that before 22.1 there
was a 22.0.

Neither was the case. 19.7 and 22.1 were the first releases of their
respective major versions.

    
    
        > So things since 22 are about about 50% faster
        > by my reckoning.
    

That's nothing to the goal post being moved by 100% :)

You were claiming that Emacs had adopted some modern fashion of more frequent
releases.

That's simply not the case. They had a really difficult 22.1 release, but
otherwise it's been pretty consistent since 1993, way before this supposed
fashion took off.

1\.
[https://www.wolframalpha.com/input/?i=May+22,+1993+to+Octobe...](https://www.wolframalpha.com/input/?i=May+22,+1993+to+October+20,+2001)

2\.
[https://www.wolframalpha.com/input/?i=June+2,+2007%09to+May+...](https://www.wolframalpha.com/input/?i=June+2,+2007%09to+May+28,+2018)

------
Pazzaz
What can the compiler actually do with '__builtin_expect_with_probability'? I
understand that '__builtin_expect' can be used to choose which branch to
prioritize but can you expect the optimizer to get better by having a
probability attached?

~~~
TheSoftwareGuy
The compiler can choose which implementation to generate based on the actual
expected performance gain in the happy case, the performance loss in the not
happy case and use the probability to decide whether its actually worth the
trade off

------
jedisct1
Can GCC compile to WebAssembly yet?

------
brimstedt
off topic, but how come these pretty much text only mail archives adapt so bad
to mobile browsers?

I have to zoom and scroll back and forth to read them..

~~~
mlindner
Because it's a very simple HTTP 1.1 page with a block of text wrapped in
<pre></pre> tags with fixed newlines. Preformmated text means your browser
doesn't reformat it.

~~~
WalterGR
...which, it should be mentioned, is a consequence of this mailing list - and
most similar ones - culturally preferring plain text formatting of emails
rather than HTML.

------
rwj
Does anyone know why the official docker images stop at version 8?

[https://hub.docker.com/_/gcc](https://hub.docker.com/_/gcc)

~~~
comex
Because in GCC's confusing versioning scheme [1], "GCC 9.0" was never a stable
release; that version number was used exclusively for development builds. So
GCC 9.1 is the first GCC 9 worth packaging, and it just came out. (And by the
time of my comment, the Docker page you linked has already been updated to
mention it.)

[1] [https://gcc.gnu.org/develop.html](https://gcc.gnu.org/develop.html)

------
fwsgonzo
Anyone know how to manually build with LTO? How to call lto-wrapper and deal
with the temporary objects created by lto1?

