
GCC 8.1 Released - edelsohn
https://gcc.gnu.org/ml/gcc/2018-05/msg00017.html
======
gchp
I did not realise GCC supported Go until reading these release notes. What
advantage/reason would I have for using GCC over the standard Go compiler?

~~~
pjmlp
Performance, GCC does more optimization passes than the reference Go compiler.

Supported platforms.

Also it does have some extension pragmas and is easier to use for something
like trying to use Go baremetal.

~~~
benesch
Before you get too excited about possible performance wins, note that gccgo
turns out to be much slower than gc (the standard Go compiler) on a lot of
real workloads. Here's one such benchmark, taken recently, though it's
admittedly a microbenchmark [0]. Dave Cheney found similar results, though
quite a while ago [1].

gccgo didn't support escape analysis for quite a long time, which meant that
the performance cost of the increased heap allocations absolutely dwarfed
whatever performance gain you got from GCC's smarter optimizations. I _think_
it's recently gained support for escape analysis—it's actually quite difficult
to find information about this, and whether you need a compiler flag to enable
it, etc.—but I don't think that's going to tip the performance scales in
gccgo's favor. EDIT: See below: 8.1 ships on-by-default escape analysis!

The primary motivations for gccgo, at least to my understanding, were a)
having a second reference implementation that could find bugs in gc and the
language specification, and b) support for esoteric platforms that will likely
never make it into gc. The announcement of gccgo has more information about
its motivation, though it makes some claims about performance that haven't
stood the test of time [2].

[0]: [https://groups.google.com/forum/#!msg/golang-
nuts/mjTmIkWKZ6...](https://groups.google.com/forum/#!msg/golang-
nuts/mjTmIkWKZ6k/L840PrnAAAAJ)

[1]: [https://dave.cheney.net/2013/11/19/benchmarking-
go-1-2rc5-vs...](https://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs-
gccgo)

[2]: [https://blog.golang.org/gccgo-in-gcc-471](https://blog.golang.org/gccgo-
in-gcc-471)

~~~
pavanky
Looks like they solved those issues in 8.1

    
    
        GCC 8 provides a complete implementation of the Go 1.10.1 user packages.
        The garbage collector is now fully concurrent. As before, values stored on the stack are scanned conservatively, but value stored in the heap are scanned precisely.
        Escape analysis is fully implemented and enabled by default in the Go frontend. This significantly reduces the number of heap allocations by allocating values on the stack instead.

~~~
smitherfield
"As before, values stored on the stack are scanned conservatively"

Why would values on the stack be garbage-collected at all? Do they mean
scanning the stack for live references?

~~~
gmueckl
I read this as "if it is on the stack and looks like a reference when you
squint your eyes, then we treat it as a reference" compared to objects on the
heap where the GC seems to know the exact location of all references.

~~~
FullyFunctional
Right that's the standard conservative garbage collection. However, new
results show that it's significantly worse than a precise collector (reference
pending).

~~~
BlackFingolfin
I'd love to see that reference, as I've not yet seen an example where this was
true in practicd, but know several examples where it is definitely false (e.g.
we use a modification of the Julia GC which uses consevative stack scanning to
allow interop with another system, and it seems to perform very well).

~~~
FullyFunctional
Sorry for the late follow up. Hopefully you're still around to notice.
Apparently there was previous HN discussion on this, but I haven't seen it (or
looked for it): [https://www.excelsiorjet.com/blog/articles/conservative-
gc-i...](https://www.excelsiorjet.com/blog/articles/conservative-gc-is-it-
really-that-bad/)

------
sevensor
> Some code that compiled successfully with older GCC versions might require
> source changes, see
> [http://gcc.gnu.org/gcc-8/porting_to.html](http://gcc.gnu.org/gcc-8/porting_to.html)
> for details.

I followed the link, and almost all of the changes are C++ related. The
exception is a change to the way some Fortran subroutines are called from C.

------
jordigh
Hm, I don't see any mention of D, which is what I was most excited about. I
know that D has been merged into gcc, but is it not there for this release
yet? Will it be in the next release?

edit: Oh well, gdc 8.1 is there in the Debian repos. I'll ask Iain Buclaw what
happened. Maybe gdc will get released with the next gcc. Looks like the merge
wasn't quite complete in time for 8.1. I can be patient.

~~~
pjmlp
Apparently the process was stalled again. Check the forums.

------
wyldfire
Cool new/improved warnings:

> The -Wrestrict option introduced in GCC 7 has been enhanced to detect many
> more instances of overlapping accesses to objects via restrict-qualified
> arguments to standard memory and string manipulation functions such as
> memcpy and strcpy.

> The -Wold-style-cast diagnostic can now emit fix-it hints telling you when
> you can use a static_cast, const_cast, or reinterpret_cast.

------
gchp
Link to the release notes:
[https://gcc.gnu.org/gcc-8/changes.html](https://gcc.gnu.org/gcc-8/changes.html)

------
dooglius
> signed integer overflow is now undefined by default at all optimization
> levels

Now I'm all for this at -O1 and above, but having this enabled by default and
-O0 [0] is just reckless. Default/-O0 should consist of only completely safe
transformations like constant folding, with UB-based stuff only performed when
optimizations are explicitly enabled.

[0] compare [https://godbolt.org/g/ufDu1n](https://godbolt.org/g/ufDu1n) on
trunk vs the behavior on 7.3 and below

~~~
lyricaljoke
I think your complaint is reasonable, but I also can see their logic in making
what's considered UB consistent for -O0 and other optimization levels. The
reason is that for most use cases, I think it's pretty typical to develop and
debug with -O0 and compile for release with stronger optimizations and other
options basically unchanged. There's an argument that in this case, making UB
consistent for -O0 might expose code that relies on UB earlier in the process,
whereas before it may have been found much later (or never!).

I understand that there are some use cases where teams release binaries
compiled with -O0 if they've identified that avoiding unexpected effects of
aggressive optimization is more important than raw performance. But in this
case, it seems like the right solution is to allow such teams to specifically
opt in to allowing overflow via -fwrapv.

~~~
wilun
You can not expect any consistency with UB.

~~~
lyricaljoke
I don't disagree, and I'm not sure what about my comment would suggest that I
expect consistency there. What I was arguing was that any code relying on UB
is dangerous / broken, so it's a good idea to surface any underlying code
issues at all optimization levels by standardizing how it's handled.

------
greptomania
I greatly appreciated the implementation of AddressSanitizer in gcc7, and am
happy to see it receive more attention in gcc8. Thank you!

~~~
jwilk
Just to be clear, ASan is available in GCC since 4.8:

[https://gcc.gnu.org/gcc-4.8/changes.html](https://gcc.gnu.org/gcc-4.8/changes.html)

~~~
greptomania
Wow. I had no idea. Thank you!

------
jason_slack
Has anyone had luck getting newer versions of gcc to run on a Parallella board
(16-core Epiphany RISC SOC and Zynq SOC (FPGA + ARM A9))?

It still has 4.9 which isn't bad, I'd just like to use new c++ functionality.

------
RandomCSGeek
If anyone wants to try this release for C and C++ languages, I have created a
Docker image based on Alpine Linux, which you may use.
[https://hub.docker.com/r/infinitecoder/gcc/tags/](https://hub.docker.com/r/infinitecoder/gcc/tags/)

------
saagarjha
> The C++ front-end now has experimental support for some parts of the
> upcoming C++2a draft, with the -std=c++2a and -std=gnu++2a options, and the
> libstdc++ library has some further C++17 and C++2a draft library features
> implemented too.

Wow, did they finish C++17 support already?

~~~
jadbox
When is C++ getting simple networking support in its stl? Is it this C++2a?

~~~
asamarin
Yes; C++20 seems likely. See
[https://isocpp.org/std/status](https://isocpp.org/std/status)

------
known
Does it break Boost libraries?
[https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries)](https://en.wikipedia.org/wiki/Boost_\(C%2B%2B_libraries\))

~~~
arnon
Every new version of GCC breaks some kind of Boost related stuff for us. I
haven't tested, but I'm going to assume it does.

------
fithisux
Unfortunately gcc-dlang/gdc is not on this release.

------
ape4
The start of the release notes sounds like the start of an infomercial ;)

"Are you tired of your existing compilers? Want fresh new language features
and better optimizations? Make your day with the new GCC 8.1!"

