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

81–87 of 87 posts

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

#81

Post by kirab »

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.

Starting with C++17 evaluation order in this case (and most other cases) is finally specified and standardized!

This is the accepted proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p014...

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

#83

Post by a_t48 »

belorn wrote: post #78
a_t48 wrote: post #73

Earlier quoted context omitted.

At my last company, clang let us do codegen for serialization (for a game like project). If clang had been copyleft we would have had to use a different solution - though we had intended/hoped on releasing our core libraries as open source, we weren't in a good place to do so.

As can be seen in the recent discussion on steam developer fees, some game developers are advocating that the initial cost of releasing games should be increased. It would reduce competition. Having a proprietary c++ compiler plug-in be a requirement would server a similar purpose, limiting competition to established developers and those few who are willing to pay the initial price.

Hmm? I'm not sure how this is relevant - this wasn't a compiler plugin and is strictly not necessarily for 95% of developers out there- we just had extraordinary requirements that were best served by parsing our classes. Which developers are asking for higher initial prices? If they are asking for them, it's not to reduce competition - I don't know a single developer I've met who wants less games out there - it's because games are Fucking expensive to make nowadays. Consumers have higher standards of quality these days unless you go into a niche genre. (This is part of why 2d platformers are so common with indie developers - 2d is way cheaper to make than 3d)

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

#84

Post by xolve »

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…

So what is the state of GCC here. Would they open up internals so people can use them?

I wish they stop playing the political stand here since LLVM is being adopted more and more.

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

#85

Post by Sanddancer »

cyphar wrote: post #75
Sanddancer wrote: post #72

Earlier quoted context omitted.

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

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

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.

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

#86

Post by afrisch »

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).

I don't think so. Both bytecode and native evaluate right-to-left.

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

#87

Post by ufo »

afrisch wrote: post #86
ufo wrote: post #41

Earlier quoted context omitted.

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).

I don't think so. Both bytecode and native evaluate right-to-left.

I swear that I remember having programs that could behave differently in the bytecode and native compiler. Perhaps I'm remembering an older version of the compiler or another order-of-evaluation issue other than function parameters?
Post reply on HN