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

GCC 10.1 Released

gcc.gnu.org

Post reply on HN
Print view View original

81–90 of 145 posts

Re: GCC 10.1 Released

#81

Post by petters »

tele_ski wrote: post #72
CoolGuySteve wrote: post #39

Earlier quoted context omitted.

My project uses g++ but I’ve been using a clang static-analysis step in my CI pipeline for a while now. Compiling with clang is much, much slower but it finds interesting errors sometimes. I only had to ifdef out one code section that it couldn’t understand (something about indexing an array with a constexpr function returning an enum class from a template parameter). It depends on the project, but this one and anoth…

Interesting that your build times are slower with clang. I've found on most of my projects clang is roughly 30% faster to compile in debug, but release I haven't seen a huge difference between the two.

Perhaps they are slower because Clang is doing static analysis in this case.

Re: GCC 10.1 Released

#82

Post by cheez »

tele_ski wrote: post #72
CoolGuySteve wrote: post #39

Earlier quoted context omitted.

My project uses g++ but I’ve been using a clang static-analysis step in my CI pipeline for a while now. Compiling with clang is much, much slower but it finds interesting errors sometimes. I only had to ifdef out one code section that it couldn’t understand (something about indexing an array with a constexpr function returning an enum class from a template parameter). It depends on the project, but this one and anoth…

Interesting that your build times are slower with clang. I've found on most of my projects clang is roughly 30% faster to compile in debug, but release I haven't seen a huge difference between the two.

Nope, also slower for me.

Re: GCC 10.1 Released

#83

Post by TeaDude »

qalmakka wrote: post #19
DyslexicAtheist wrote: post #2

I love the built-in static analyzer -fanalyzer option in gcc-10. [1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

Isn't it very similar to something Clang has had for years?

Clang has it although I've personally never tried it due to the horrible rigamarole of setting it up.

In GCC it's a compiler flag. In LLVM it's a convoluted process automated by either an irritating perl/python script (The python one isn't included by default for some reason despite being far more common these days) or AN ENTIRE WEB SERVER TO OUTPUT TEXT (Which thankfully isn't included by default).

I'm sure you could set it up in make but since my projects aren't large scale enough to really need it I can't be bothered, even if it's one of those things you'll probably only need to write once and can just copy and paste ad-infinitum.

Re: GCC 10.1 Released

#84

Post by hinkley »

MauranKilom wrote: post #47

> Extended characters in identifiers may now be specified directly in the input encoding (UTF-8, by default), in addition to the UCN syntax (\uNNNN or \UNNNNNNNN) that is already supported: static const int π = 3; int get_naïve_pi() { return π; } Lovely!

The next obfuscated code competition is sure gonna be interesting.

Re: GCC 10.1 Released

#85

Post by throwaway894345 »

zorked wrote: post #65
malkia wrote: post #63

Earlier quoted context omitted.

I wish Math used normal english, not greek letters - english is my second language too..

They are latin letters, not english. Unless you mean futhorc. Which would be awesome.

He didn't say "english letters", he said "english" which is a language. The implication is that we should use conventions (including potentially whole words) that are familiar to the English-literate world and not Greek glyphs.

Re: GCC 10.1 Released

#86

Post by CoolGuySteve »

petters wrote: post #81
tele_ski wrote: post #72

Earlier quoted context omitted.

Interesting that your build times are slower with clang. I've found on most of my projects clang is roughly 30% faster to compile in debug, but release I haven't seen a huge difference between the two.

Perhaps they are slower because Clang is doing static analysis in this case.

Static analysis is a lot slower but regular clang++ is also significantly slower than g++, like a 4-5 minute build time vs 2:30 on g++.

It might have something to do with a heavy usage of templates in a few files, I don't know.

Clang's autovectorization is better in a few functions I disassembled but otherwise the generated code doesn't benchmark any faster, it's better in some places, worse in others.

Re: GCC 10.1 Released

#87

Post by rumanator »

jcelerier wrote: post #71
rumanator wrote: post #45

Earlier quoted context omitted.

> Yes, and updating compilers don't prevent that at all. You do understand that ABI backward compabitility is not ensured, don't you? https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html Some software packages even break between distro releases. The primary value of a distro is to provide a fixed platform that application developers and users can safely target. Risking ABI breakups just because a rare number of u…

Let me quote exactly the page you linked : > The GNU C++ compiler, g++, has a compiler command line option to switch between various different C++ ABIs. This explicit version switch is the flag -fabi-version. If you want to target a given distro, you -fabi-version this distro's ABI, just like you set -mmacosx-version-min on mac or set _WIN32_WINNT on windows

That's something that might be useful for one of those rare end-users who for some reason want to try to build something with a bleeding edge compiler.

That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages.

I should not be forced to endure a brittle and fragile and overly-complex compilation process just because a random guy somewhere had a whim about taking a compiler out for a spin.

The world expects stability. If you wish to try out some stuff, just download the compiler and build the damn thing yourself. Hell, odds are that there's already a PPA somewhere. So where's the need to screw over everyone?

Re: GCC 10.1 Released

#88

Post by tspiteri »

pkolaczk wrote: post #24
simias wrote: post #17

Earlier quoted context omitted.

> Sure you can have that with `unsafe` The parent was talking about the borrow checker so I only was talking about safe Rust code. Obviously if you consider that the entire C/C++ codebase is in a big unsafe {} block it'll work... because it won't do anything at all.

From Rust docs: It's important to understand that unsafe doesn't turn off the borrow checker or disable any other of Rust's safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these four features that are then not checked by the compiler for memory safety.

One of those four features is dereferencing pointers, and unlike references, pointers are not checked by the borrow checker. So you could bypass the borrow checker using unsafe code in a way, though most probably you should not.

Re: GCC 10.1 Released

#89

Post by jcelerier »

rumanator wrote: post #87
jcelerier wrote: post #71

Earlier quoted context omitted.

Let me quote exactly the page you linked : > The GNU C++ compiler, g++, has a compiler command line option to switch between various different C++ ABIs. This explicit version switch is the flag -fabi-version. If you want to target a given distro, you -fabi-version this distro's ABI, just like you set -mmacosx-version-min on mac or set _WIN32_WINNT on windows

That's something that might be useful for one of those rare end-users who for some reason want to try to build something with a bleeding edge compiler. That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages. I should not be forced to endure a brittle and fragile and overly…

> That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages.

but why would you have "random ABI breakages" ? there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 to make a windows software for instance, so what makes you think Linux would be any different if you could install a compiler version of your choosing instead of the one fixed by Ubuntu / Debian / whatever. Why is it a problem for C/C++ but not for Go / Rust / every other native-compiled language in the universe ?

Re: GCC 10.1 Released

#90

Post by klodolph »

jcelerier wrote: post #73
klodolph wrote: post #48

Earlier quoted context omitted.

> [...] and updating compilers don't prevent that at all. This is incorrect. In practice, for larger code bases, upgrading to a newer version of GCC or Clang is something that must be done purposefully, and you must test. Sometimes it turns out that your code relies on some compiler behavior which has changed. Sometimes newer compilers are stricter than older compilers. There are plenty of real-world cases of these p…

> This is incorrect. In practice, for larger code bases, upgrading to a newer version of GCC or Clang is something that must be done purposefully, and you must test. Sometimes it turns out that your code relies on some compiler behavior which has changed. Sometimes newer compilers are stricter than older compilers. There are plenty of real-world cases of these problems! So if you hit issues, do what you do on every o…

> So if you hit issues, do what you do on every other system which is "installing older Xcode / Visual Studio" ? That would not be an issue at all if the toolchain wasn't vendored as part of the distro, you'd just have something like rustup that allows you to use whatever version of the toolchain your project requires.

Or you could switch to LTS, which achieves the same thing.

Post reply on HN