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

91–100 of 145 posts

Re: GCC 10.1 Released

#91

Post by ndesaulniers »

TeaDude wrote: post #83
qalmakka wrote: post #19

Earlier quoted context omitted.

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 coul…

Lest other people get the wrong impression from someone who's admitted not even trying it, running Clang's static analyzer is as simple as switching cc with scan-build. You can even drive it from clang-tidy. No Perl or Python setup in my experience.

Re: GCC 10.1 Released

#92

Post by pjmlp »

simias wrote: post #10
glouwbug wrote: post #7

Earlier quoted context omitted.

Imagine if -fanalyze was like rusts borrow checker

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if y…

While it isn't at Rust level, that doesn't stop Google and Microsoft from trying.

"Update on C++ Core Guidelines Lifetime Analysis. Gábor Horváth. CoreHard Spring 2019"

https://www.youtube.com/watch?v=EeEjgT4OJ3E

Re: GCC 10.1 Released

#93

Post by pjmlp »

glouwbug wrote: post #7
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...

Imagine if -fanalyze was like rusts borrow checker

That is what Microsoft and Google are trying to do with C++ Lifetime Profile.

https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...

"Update on C++ Core Guidelines Lifetime Analysis. Gábor Horváth. CoreHard Spring 2019"

https://www.youtube.com/watch?v=EeEjgT4OJ3E

While it might never be Rust like due to language semantics, it is way better than not having anything.

Re: GCC 10.1 Released

#95

Post by rumanator »

jcelerier wrote: post #89
rumanator wrote: post #87

Earlier quoted context omitted.

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 y…

> there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019

You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't bridged by mindlessly stating that GCC and mscv are both compilers.

ABI is the bane of C++. Why are you posting comments on a thread about C++ and the problems created by ABI if you are oblivious to this? The only thing you're managing to do is generate noise and make everyone waste their time with your posts.

> so what makes you think Linux would be any different

Because it is, and at many levels. Just the fact that you are entirely oblivious to this basic fact is enough to convince anyone not to bother with any further replies to this thread.

Re: GCC 10.1 Released

#96

Post by coldtea »

throwaway894345 wrote: post #85
zorked wrote: post #65

Earlier quoted context omitted.

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.

>The implication is that we should use conventions (including potentially whole words) that are familiar to the English-literate world and not Greek glyphs.

The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs.

And that's just for humanities.

The mathematic and physics -literate world, doubly so. Everybody uses pi, theta, sigma (e.g. the summation formula) etc symbols...

Re: GCC 10.1 Released

#97

Post by simias »

zozbot234 wrote: post #60
simias wrote: post #10

Earlier quoted context omitted.

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if y…

> for instance initializing a structure or array partially if you're sure that nobody is going to use the initialized portion. Or having multiple mutable pointers/reference to the same object. Rust supports MaybeUninit for the former example, and unsafe raw pointers for the latter. It needs unsafe because these patterns are not safe in the general case and absent an actual proof of correctness embedded in the source…

That's my point though, in both cases the developer needs to add additional syntax to make the intent clear. "Naive" Rust code that tries to do that stuff is rejected by the compiler.

I've expressed myself poorly in my original comment and apparently it looks like I was criticizing Rust but I wasn't. I was just pointing out that safety didn't come "for free" by toggling a compiler flag, you have to change the way you code some things. If C and C++ were to become safe languages, code would need to be rewritten using things like MaybeUninit, split_at_mut, RefCell etc...

Re: GCC 10.1 Released

#98

Post by moonchild »

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.

My build times are identical between GCC and Clang (debug and release).

But TCC is 10x faster than both of them.

Re: GCC 10.1 Released

#99

Post by Freaky »

TeaDude wrote: post #83
qalmakka wrote: post #19

Earlier quoted context omitted.

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 coul…

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

    -% scan-build10 make
    scan-build: Using '/usr/local/llvm10/bin/clang-10' for static analysis
    ...
    scan-build: No bugs found.
What could ever have driven them to such a long and convoluted setup process?

Re: GCC 10.1 Released

#100

Post by jcelerier »

rumanator wrote: post #95
jcelerier wrote: post #89

Earlier quoted context omitted.

> 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 y…

> there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't b…

> Windows is not Linux and GCC is not msvc++

That does not mean anything. Linux can be whatever people with enough free time want it to be. It's 100% possible to imagine a Linux-based system with a Windows-like userspace and pacing. Hell, technically you could just ship the Linux kernel, an init system, Wine and live in an almost windows-y world - even cl.exe works under wine.

> Why are you posting comments on a thread about C++ and the problems created by ABI if you are oblivious to this?

Because it's an entirely self-inflicted problem, caused by putting toolchains (among two thousand other things) in distros.

Again, why do people have no trouble shipping Rust which has zero ABI guarantees to ten year old Ubuntus and C++ couldn't ? The answer is, it totally can if you just let it and let go of shipping dev packages in distros, instead relying on C++-specific package managers such as conan or vcpkg for your dependencies.

I build my own software with latest versions of clang, Qt, boost and have no trouble distributing it to fairly old distros.

> Because it is, and at many levels.

yes, I'm asking about what could be, not what is ?

Post reply on HN