Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC 7 Release Series – Changes, New Features, and Fixes

gcc.gnu.org

Post reply on HN
Print view View original

21–30 of 87 posts

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#21

Post by anon1385 »

Bino wrote: post #2

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.

As far as I can tell GCC is still inferior when it comes to warning about uninitialized variables.

Clang: https://godbolt.org/g/BVfy81

GCC: https://godbolt.org/g/uIN1gG

See the famous and now 12 years old GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#22

Post by loeg »

hannob wrote: post #10
Bino wrote: post #2

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.

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…

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.

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#23

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

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#24

Post by ymse »

adrianN wrote: post #20
kuschku wrote: post #17

Earlier quoted context omitted.

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.

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

LLVM is free software. The term you are looking for is "copyleft".

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#25

Post by arca_vorago »

adrianN wrote: post #20
kuschku wrote: post #17

Earlier quoted context omitted.

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.

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

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.

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#26

Post by bastawhiz »

mindleyhilner wrote: post #23

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.

Naive question: if you move towards the exit of a function, wouldn't that be beneficial? That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#27

Post by Sylos »

adrianN wrote: post #20
kuschku wrote: post #17

Earlier quoted context omitted.

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.

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

Open-source means the exact same thing as free software, there's just an ideological difference between the two.

https://opensource.org/osd

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#28

Post by DannyBee »

mindleyhilner wrote: post #23

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.

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)

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#29

Post by mindleyhilner »

bastawhiz wrote: post #26
mindleyhilner wrote: post #23

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.

Naive question: if you move towards the exit of a function, wouldn't that be beneficial? That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?

The point of hoisting towards entry is to reduce code size, as the changelog indicates. It's safe to hoist the expression from program points P_{0..i..n-1} to some point Q that dominates all P_i if the expression is available at each P_i. That reduces the number of occurrences by n - 1. It's a basic corollary of PRE.

This is identical to what LLVM's load-store motion does for loads, except for all expressions and not just loads.

Re: GCC 7 Release Series – Changes, New Features, and Fixes

#30

Post by DannyBee »

bastawhiz wrote: post #26
mindleyhilner wrote: post #23

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.

Naive question: if you move towards the exit of a function, wouldn't that be beneficial? That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?

In practice, you want to do both.IE hoist everything you can, sink everything you can.

But not because of "That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?"

If the function terminates early, and you've moved the expression computation before or after an early termination point, you've by definition changed what paths it is computed on (unless it was already computed there). That is not legal in all cases (it's speculative PRE/PDE)

PRE and VBE (which is what this is) guarantee that the expression is still computed at on the same paths. They just make it so it's computed once.

What is happening here is really a size optimization. If it can prove that it is always executed, it has one copy of the computation, instead of multiple ones.

Post reply on HN