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

41–50 of 87 posts

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

#41

Post by ufo »

qb45 wrote: post #19
joatmon-snoo wrote: post #13

Earlier quoted context omitted.

My first experience with UB: foo(bar(), bar()); (where bar() was stateful) Discovering that g++ and clang++ compiled to one that did what I wanted and one that didn't was an interesting experience.

It gets even funnier in OCaml where they nominally defined it UB in order to get the freedom to make the only existing implementation always 100% reliably evaluate right-to-left, which reportedly was better for performance or something :) And before somebody wonders about currying and eager evaluation, the problem is not functions but type constructors, which aren't curried.

The ocaml one is very annoying because the bytecode interpreter reliably evaluates arguments left-to-right but when you compile to native code it reliably evaluates right-to-left (or the other way around, I don't remember).

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

#42

Post by gumby »

qb45 wrote: post #9
srean wrote: post #3

Earlier quoted context omitted.

For gcc-4.3 this was a no contest, clang was clearly better. However, gcc has made up a lot of ground over the years, to the point that I now consider gcc's template based error messaes better. It is very difficult to keep personal judgement and tastes out of the equation so ymmv. If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anywa…

> If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anyway and I should be doing more of that. It actually is a good idea to regularly build and test C/C++ codebases with both gcc and clang because not only error diagnostics are different but also warnings and optimizations, including crazy optimizations exploiting undefined behavior.…

Yes! We have written a new package and compiling with the G++-6 -Wall -Werror .... and clang-++-4 -Weverything -Werror finds different bugs and different diagnostics.

Although I have a long gcc bias I do use clang first as it is still faster to compile. Gcc still generates faster code for our codebase (and more importantly: faster where it matters to us) but they are pretty close and if I really had to decide between one and the other it would hardly matter.

G++-7-not-quite-released appears to have better C++17 support. We may be the only people who care yet :-)

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

#43

Post by ot »

joatmon-snoo wrote: post #13
qb45 wrote: post #9

Earlier quoted context omitted.

> If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anyway and I should be doing more of that. It actually is a good idea to regularly build and test C/C++ codebases with both gcc and clang because not only error diagnostics are different but also warnings and optimizations, including crazy optimizations exploiting undefined behavior.…

My first experience with UB: foo(bar(), bar()); (where bar() was stateful) Discovering that g++ and clang++ compiled to one that did what I wanted and one that didn't was an interesting experience.

That's not UB. Argument evaluation order is unspecified, not undefined.

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

#44

Post by [deleted] »

ufo wrote: post #41
qb45 wrote: post #19

Earlier quoted context omitted.

It gets even funnier in OCaml where they nominally defined it UB in order to get the freedom to make the only existing implementation always 100% reliably evaluate right-to-left, which reportedly was better for performance or something :) And before somebody wonders about currying and eager evaluation, the problem is not functions but type constructors, which aren't curried.

The ocaml one is very annoying because the bytecode interpreter reliably evaluates arguments left-to-right but when you compile to native code it reliably evaluates right-to-left (or the other way around, I don't remember).

[deleted]

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

#45

Post by cat199 »

arca_vorago wrote: post #25
adrianN wrote: post #20

Earlier quoted context omitted.

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

Copyleft software presumes software exists in a vaccum where money and funding aren't an issue in other areas of society..

If everything in computer software is copylefted, the status quo in the rest of the non-software economy persists.

Further, examples of AGPL 'free software' for the web backed by the dominant cloud service provider essentially give them an unlimited monopoly on that particular service, since, as copyright holder, they will be the only party able to create a proprietary fork which is better than the competition..

More philosophically:

The spirit of the law is always greater than the law itself..

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

#46

Post by gribbly »

anon1385 wrote: post #34
gribbly wrote: post #14

Earlier quoted context omitted.

Maybe, maybe not. I've been seeing this comment for the past 7-6 years, and GCC still delivers better performance on the majority of real-world programs I benchmark (mostly compression). What I find very strange though is that some people seemingly want one of these projects to die. As is evident from many of the replies in this thread, having two great compiler toolchains with which to test your code is a great adva…

>What I find very strange though is that some people seemingly want one of these projects to die. I'm not sure which side you were addressing here, so I'll cover both Stallman wants the LLVM project to die for political reasons (he described it as "a terrible setback for our community" [1]). His argument is basically that LLVM can be used by non-free software, so it's mere existence is negative for the world because…

>On the other side, one of the problems people have with GCC is that it's run by people who actively want to make worse software for political reasons.

Well, for an end user those 'political' reasons are often practical benefits.

Having features only available as proprietary add-ons or through proprietary forks, or being locked out of running the code of your choice on hardware you've bought, are things I find very unappealing.

Of course there are downsides with copyleft as well, because there is no perfect solution to this problem.

Personally I'm favoring permissive licensing for projects where there is little or no incentive for commercial proprietary forks, and copyleft for projects where there is (typically end user targeted).

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

#47

Post by greenhouse_gas »

arca_vorago wrote: post #25
adrianN wrote: post #20

Earlier quoted context omitted.

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

While I personally like the GPL philosophy, I think that its days in protecting free software is numbered.

The purpose of the GPL was to encourage companies to publish their software under the GPL (want to use readline, got to use GPL). The long term goal was to create an environment where GPL software was so much better than the alternative that closed-source software would just whither.

This made sense in the 1980s. Remember that gnu was started when RMS found that he couldn't modify a program he needed - at the dawn of proprietary software.

This was a time when software writing was a small-scale operation (emacs was written by one? individual, Unix by two or three, etc.) and college students/professors could easily outnumber commercial software houses.

It actually worked for a while - gnu actually won a objective-C compiler purely due to the GPL.

Now, on the other hand, nowadays software companies are huge and have huge teams. Even without llvm's academic base, Apple would have enough cash to build it on their own.

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

#48

Post by pjmlp »

greenhouse_gas wrote: post #47
arca_vorago wrote: post #25

Earlier quoted context omitted.

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

While I personally like the GPL philosophy, I think that its days in protecting free software is numbered. The purpose of the GPL was to encourage companies to publish their software under the GPL (want to use readline, got to use GPL). The long term goal was to create an environment where GPL software was so much better than the alternative that closed-source software would just whither. This made sense in the 1980s…

Now that printer driver will be written with code taken from a Github project MIT/BSD license and the company won't make it available to anyone, using firmware encrypted with TPM, thus getting full circle to those days while having higher profits for the printer company, thanks to lower development costs.

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

#49

Post by DannyBee »

mindleyhilner wrote: post #35
DannyBee wrote: post #32

Earlier quoted context omitted.

This is identical to what LLVM's load-store motion does for loads, except for all expressions and not just loads. It's actually not. It's what GVNHoist does, but not MLSM. MLSM only handles diamonds. In any case, because the GCC implementation is written on top of a sane PRE infrastructure, it is like 50 lines of code to do this :)

It's actually not. It's what GVNHoist does, but not MLSM. MLSM only handles diamonds. Fine, it's what MLSM aspires to: http://llvm-cs.pcc.me.uk/lib/Transforms/Scalar/MergedLoadSto... (:

Writing "TODO: generalize to other regions" in a crazy N^3/N^4 approach to merging load/stores is like writing "TODO: solve prime number conjecture" in somebody's hand-rolled two's complement addition code.

Maybe it happens, but it ain't gonna happen with anything like this code :)

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

#50

Post by greglindahl »

joatmon-snoo wrote: post #13
qb45 wrote: post #9

Earlier quoted context omitted.

> If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anyway and I should be doing more of that. It actually is a good idea to regularly build and test C/C++ codebases with both gcc and clang because not only error diagnostics are different but also warnings and optimizations, including crazy optimizations exploiting undefined behavior.…

My first experience with UB: foo(bar(), bar()); (where bar() was stateful) Discovering that g++ and clang++ compiled to one that did what I wanted and one that didn't was an interesting experience.

The SGI compiler (now Open64) evaluates function arguments from right to left, unlike most other compilers. As a result we (PathScale) had to educate numerous users that the order is not guaranteed.
Post reply on HN