Hacker News new | past | comments | ask | show | jobs | submit login
GCC 9.1 Released (gnu.org)
219 points by edelsohn 18 days ago | hide | past | web | favorite | 44 comments

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

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

gcc is not particularly hard to build from source either.

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)

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

Under Ubuntu 18.04 I followed the instructions here: 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.

Weird. Usually when it passes configure stage, then you're more or less good to go.

Usually it's just this sequence:

wget gcc... whichever

untar it and go into the directory

within that directory ./contrib/download_prerequisites

outside of that directory create a build directory, go in there and do a config. I usually do (for example in 9.1 case, but it has been the same forever now):

../gcc-9.1.0/configure --prefix=<my_home_dir>/tools/gcc-9-1-0 --enable-languages=c,c++,ada --disable-multilib --enable-checking=release --with-pkgversion='GCC Keyframe'

For Ada you have to have an Ada enabled compiler already, so omit ada

and after that it's simple make and then make install

I also have functions in my .zshrc with which I set envs so I can easily switch between gcc versions (and linkers) and that's it.

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

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.

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

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.

Its one error after name mangling.

Interesting... never had any trouble on CentOS or Fedora. Maybe not enough gcc developers use Ubuntu...

Related link: GCC 9: Link-time and inter-procedural optimization improvements https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-int...

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.

"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

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

This is extremely common?

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

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.


Definitely not 'subtle difference'; when has it ever meant that? It means a nonstandard extension.

This will be annoying to someone whose struct dumps suddenly stop working.

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

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.

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

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.

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.

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

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

1. https://en.wikipedia.org/wiki/GNU_Emacs#Release_history

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.

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

2. https://www.wolframalpha.com/input/?i=June+2,+2007%09to+May+...

Yet other libraries/compilers (e.g. CUDA/nvcc) will still bail out if the major version number of gcc is different than they expect...

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?

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

Can GCC compile to WebAssembly yet?

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

Because instead of serving it as plaintext they (stupidly) serve it as HTML and are then forced to wrap it in pre tags as a hack to preserve formatting without fully converting from plaintext to HTML.

Any other approach but this would have worked fine.

The page has links, so I don't see how serving it as plaintext would work.

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

Even in landscape?

Do you have a problem with text in landscape for this particular URL, or you find that you frequently do? Are you on an iPhone? If no, yes, and yes, this may shed some light: https://stackoverflow.com/questions/2710764/preserve-html-fo...

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.

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

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


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

I'm sure PRs are welcome: https://github.com/docker-library/gcc

It's community maintained.

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact