
GCC 7 Release Series – Changes, New Features, and Fixes - rbanffy
https://gcc.gnu.org/gcc-7/changes.html
======
Keyframe
_On mainstream native platforms, Ada programs no longer require the stack to
be made executable in order to run properly._

What does that even mean? I'm dabbling with Ada as of recently.

Also, woo!

 _Support for the RISC-V instruction set has been added._

On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also
have Clang - all available to me via switch/simple shell functions. I always
tend to have my junk work on all of those, so am in a kind of a simplistic
position to compare each. From a daily user perspective, there's not much
difference at all (clang and newer gcc). Clang's pretty warnings are almost in
GCC now as well, speed is still on GCC's side (for me at least) and all is
good in GCC and LLVM land. I'm leaning more towards GCC since I've been using
it since it became united in late 90s. I believed in it, even though people
thought of it, at the time, to be slow and shit. Look at it now! I'm using it
on MacOS (yes), Windows and Linux. I'm sure more heavyweight users will find a
lot of things GCC can improve upon though.

I know it might not be strictly in the scope of GCC's domain, but I would like
to see some static analysis and linters (like MISRA, etc.) included out of the
box with it. That would be swell.

~~~
Kenji
>What does that even mean?

I know nothing about Ada but there is a feature called called 'executable bit'
in pretty much all desktop processors since 1-2 decades. What this bit does is
it marks certain regions of memory as not executable, i.e. you're not allowed
to put the instruction pointer onto that region and let the CPU run the
instructions. This is a hardware-level feature and can be disabled in
BIOS/UEFI. Usually the stack is marked as not executable as a security
feature, so buffer overruns can't just write code on the stack and then it is
executed.

Why Ada needed this disabled is beyond me. Does it execute things on the
stack?

~~~
xyz6633
>Why Ada needed this disabled is beyond me. Does it execute things on the
stack?

I believe this is due to nested function support. There is some explanation
here: [https://stackoverflow.com/questions/34982151/executable-
ada-...](https://stackoverflow.com/questions/34982151/executable-ada-code-on-
the-stack)

------
Bino
If you compare (gcc7 and latest clang), how much in pair is gcc with clang in
terms of compilation warnings? (One of the most valuable tool of a compiler).
I'm really happy they are moving in the same direction; I've been worried
about gcc.

~~~
hannob
Where clang now clearly leads is in terms of runtime security and debugging
features. Both share asan (address sanitizer), ubsan (undefined behavior) and
tsan (threads). But msan (memory sanitizer, finds uninitialized memory use) is
only available in clang.

In terms of exploit mitigation clang now has control flow integrity and
safestack, as far as I'm aware nothing like this is available in gcc.

msan may not be such a big deal, because you could use clang for testing and
gcc for production. But I hope more people adopt stronger exploit mitigations
like CFI, and if gcc doesn't deliver them clang will win - at least for
security sensitive areas.

~~~
loeg
My understanding (and empirical anecdote) is that Clang produces inferior
debuginfo (eliding some locals' contents, even when their values are not
actually lost) that makes it more difficult to debug than binaries produced by
GCC.

asan, ubsan, tsan, and msan are important debugging features, but for my every
day use in core analysis, local variables in gdb are very important.

------
minxomat
GCC 7 also removed some boost-specific traits, some of which may impact some
libs, like was the case for TBB[1].

[1] -
[https://github.com/01org/tbb/issues/12](https://github.com/01org/tbb/issues/12)

------
caf
Some of those new warnings look very useful.

~~~
patrickmn
Clang really pushed this area forward. Good to see.

------
mindleyhilner

      It attempts to move evaluation of expressions executed on all paths to the function *exit* as early as possible, which helps primarily for code size, but can be useful for speed of generated code as well. [Emphasis added.]
    

Typo? PRE hoists upwards, so it would make sense to move closer to entry, not
exit.

~~~
DannyBee
No, it's correct. It's saying "if they are always computed, we move them up".

IE

    
    
      if (a)
        foo = a + b
      else b 
        foo = a + b
      ->
      foo = a+b
      if (a)
      else (b)

~~~
mindleyhilner
How do you move up towards exit?

~~~
evilpie
I think you have to read it like "executed on >all paths to the function exit<
as early as possible". As in, if you have an expression that is always
executed regardless which path you take before returning. It's useful to move
that expression upwards instead of having copies on the different paths to the
function exit.

------
pjmlp
Sad to see gcj getting the final shot, but the project hasn't changed much
since 2009 anyway.

------
ChuckMcM
Sigh, looks like one of my common idioms:

    
    
       if (int_value) { ... }
    

Will now be warned/failed.

~~~
fjarlq
Hmm, I wonder if that's actually true. I don't have GCC 7 anywhere to actually
test it, but the documentation[1] states:

    
    
      -Wint-in-bool-context
    

Warn for suspicious use of integer values where boolean values are expected,
such as conditional expressions (?:) using non-boolean integer constants in
boolean context, like

    
    
      if (a <= b ? 2 : 3)
    

Or left shifting of signed integers in boolean context, like

    
    
      for (a = 0; 1 << a; a++);
    

Likewise for all kinds of multiplications regardless of the data type. This
warning is enabled by `-Wall`.

[1]: [https://gcc.gnu.org/onlinedocs/gcc/Warning-
Options.html](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)

~~~
ChuckMcM
I'm guessing (again I can't really test it yet) that it will warn on it and
suggest

    
    
       if (int_value != 0) { ... }
    

To be clear about what I mean.

~~~
ajdlinux
I've just tested against GCC master and can confirm that -Wint-in-bool-context
does not trigger on this very, very standard case.

Per the examples in the documentation, it _does_ trigger when you do something
silly like "if (i < 3 ? 7 : 0)".

In fact if you read the documentation and the warning messages more closely,
it's looking for suspicious use of integer _constants_ , not integer
variables.

~~~
ChuckMcM
Awesome, and I missed the bit about constants.

------
stefantalpalaru
Great news on the gccgo front:

> Escape analysis is available for experimental use via the -fgo-optimize-
> allocs option.

------
denim_chicken
It's only a matter of time before llvm/clang overshadows gcc in every aspect,
if it hasn't already. clang probably has 10x more full-time developers than
gcc does.

~~~
kuschku
It’s a similar story as with Firefox and Chrome, and you’re sadly right.

The free software community is more than ever before at risk of being replaced
by a monopoly culture controlled by large corporations.

~~~
adrianN
That's what you get when you prefer programs that are merely open source to
free software.

~~~
arca_vorago
Exactly. It's like when evaluating things people just completely forget about
the implications of the license they use, in both specific and broad contexts.
I use and support GPL products as much as possible, even when a BSDesque
product may actually have a few advantages. I'm not 100% on that either, but I
try hard to slowly adapt and use truly foss software and get used to the
ecosystem mentality changes they require.

I wish people, particularly devs, thought more about licenses and their long
term impact on freedom of the user & dev. I get tired of hearing about how
"but copyleft is less free because it restricts me", but to me that's like
saying "individual liberty under the rule of law is less free because it
prevents me from punching that dude in the face". It's some strange form of
anarchism argumentation that fails to respect the rights of others.

With all the security issues cropping up lately, I think it should be obvious
to big picture thinkers that, while not _the_ solution in itself, any real
forward thinking solutions for cyber-security must focus on keeping black
boxes out of the picture. BSD style licenses are dangerous to me because they
allow hard working peoples code to be abused and used for abuse of others.

To be fair to this particular argument though, LLVM does fall under the LSCA
license which is gpl compatible, it simple isn't copyleft, so my above rant is
more a general comment than on the topic of clang.

~~~
Sanddancer
I'd argue the opposite, that GPL style licenses make it easier to hide things
in black boxes these days. LLVM and Clang are under BSD style licenses, and
even Sony has said that being an active contributor keeps things moving along
[1] even when they don't have to contribute back. Plus, most BSD-style code
doesn't require things like copyright assignment, which can be a big brake
against people from contributing back.

Additionally, a lot of GPL software, like MySQL and BerkeleyDB, create a more
closed community because that company has a lot more ability to create their
own black box projects through dual licensing as closed source works.
Postgres, in comparison, is BSD licensed, making it much harder for a company
like Oracle to buy out pieces of the community and run away with the source
and make deals others can't. The GPL has a lot less community power to counter
those sorts of situations.

[1] [http://llvm.org/devmtg/2013-11/slides/Robinson-
PS4Toolchain....](http://llvm.org/devmtg/2013-11/slides/Robinson-
PS4Toolchain.pdf)

~~~
cyphar
GPL doesn't require copyright assignment (the two issues are completely
separate). And if the original author isn't the only copyright holder, they
can't make GPL'd code proprietary either. Which is why going GPL is a benefit
for everyone -- nobody can effectively make the software proprietary unless
there is only a single copyright holder.

With BSD-style licenses, everyone is also on an equal footing, except that now
users have no guarantees that the software they use will be maintained as free
software. At any point, a treacherous developer or company could scoop up the
talent from the community and make a maintained fork of the project
proprietary. The original project dies because of lack of talent and now free
software has helped expand the reach of proprietary software.

Note that even with copyright assignments, there are some good ones. The FSFs
( _optional_ for projects) copyright assignment has specific wording that
guarantees they will always keep the code free (and even go further to state
that it will always be copyleft and in keeping with their well-documented
philosophy). If I had a single foundation I had to pick to assign my copyright
to, it would be the FSF.

~~~
Sanddancer
That same treacherous developer can scoop up talent from a GPLed project too,
such as the examples I gave. Sourceforge used to have a GPLed, but was brought
closed, and the free version mouldered from disuse. Free software helped
expand the reach of proprietary software. The GPL is no guarantee that a free
version will always remain the most used branch either.

Going GPL also has drawbacks. Look at how Apache 2 and GPL 2 weren't
compatible because of the Apache license's patent clause. That lock-in effect
of the GPL means that your software package can't be used by the larger free
software community. Which if you're satisfied with it, fine, but some people
don't want to encumber their software as such. There's no such thing as a
universal benefit.

~~~
cyphar
> That same treacherous developer can scoop up talent from a GPLed project
> too, such as the examples I gave.

I don't understand what this sentence means? Do you mean they take the
developers and stop them from working on the original GPL version? In this
context I'm referring to the most common case which is a GPL project that has
more than one copyright holder.

In _that_ context is is not possible for a developer to take the existing work
of the developers, make a proprietary fork, and convince the developers (in a
moment of weakness) to switch and start working on the proprietary code. They
can create a new project, but that's always true and not possible to restrict
(nor would anyone want to).

> That lock-in effect of the GPL means that your software package can't be
> used by the larger free software community.

And this is the whole point of the "or any later version" clause. Every
complaint you're bringing up has already been resolved by how the GPL is used
and has worked for >20 years. Of course the GPL does have its downsides (the
whole MPLv1/CDDL thing is a real shame) but "lock-in" is not one of them
(unless you explicitly decide to lock yourself in, which is your own fault).

~~~
Sanddancer
It's absolutely possible in such a for the developer to make a fork. People
can agree to change licenses, portions can and have been rewritten. Nothing
keeps a license in stone.

I'm referring to the GPL's "no other restrictions" clauses that keeps things
from interoperating with the Eclipse public license for IBM wanting to
maintain choice of venue, the MPL, CDDL, 4-clause BSD, etc. Each of which the
FSF says, "well, if they just used our license." The GPL is absolutely a
barrier to cooperation.

