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

71–80 of 87 posts

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

#71

Post by jacquesm »

gravypod wrote: post #40
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 functions arguments are pushed onto the stack. From within the function you can think of the stack as an array. void test(a, b, c) stack[0] == a stack[1] == b stack[2] == c But to get the items in the stack in that order you have to... puch c push b push a If you wanted to do that, and still allow for left to right evaluation you could... temp_a = a temp_b = b temp_c = c push c puch b push a That would be 2x inst…

Except that in most cases that's not how it is done.

Instead, the stackframe is created in one go with a single change to the stack pointer and then the values are filled in in whatever order the compiler / language desires.

Here is a typical example using GCC:

        movq    %rsp, %rbp
        subq    $16, %rsp
        movl    $12, -4(%rbp)
        addl    $1, -4(%rbp)
        movl    -4(%rbp), %eax
        movl    $14, %edx
        movl    %eax, %esi
        movl    $12, %edi
        call    f
Which moves the parameters using registers (subject to availability) as a further optimization. The 'subq' reserves space for the stackframe with addresses relative to rbp being the parameters.

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

#72

Post by Sanddancer »

cyphar wrote: post #66
Sanddancer wrote: post #56

Earlier quoted context omitted.

I'd argue the opposite, that GPL style licenses make it easier to hide things in black boxes these days. LLVM and Clang are under BSD style licenses, and even Sony has said that being an active contributor keeps things moving along [1] even when they don't have to contribute back. Plus, most BSD-style code doesn't require things like copyright assignment, which can be a big brake against people from contributing back…

GPL doesn't require copyright assignment (the two issues are completely separate). And if the original author isn't the only copyright holder, they can't make GPL'd code proprietary either. Which is why going GPL is a benefit for everyone -- nobody can effectively make the software proprietary unless there is only a single copyright holder. With BSD-style licenses, everyone is also on an equal footing, except that no…

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 GPL 2 weren't compatible because of the Apache license's patent clause. That lock-in effect of the GPL means that your software package can't be used by the larger free software community. Which if you're satisfied with it, fine, but some people don't want to encumber their software as such. There's no such thing as a universal benefit.

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

#73

Post by a_t48 »

gribbly wrote: post #46
anon1385 wrote: post #34

Earlier quoted context omitted.

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

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.

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

#74

Post by caf »

kuschku wrote: post #17
denim_chicken wrote: post #11

It's only a matter of time before llvm/clang overshadows gcc in every aspect, if it hasn't already. clang probably has 10x more full-time developers than gcc does.

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.

There's something about a near-duopoly in technical fields that seems to encourage camps of dedicated partisans.

In addition to GCC/clang and Firefox/Chrome already mentioned, think Microsoft/Apple, Intel/AMD, nvidia/AMD, Boeing/Airbus, Playstation/XBOX...

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

#75

Post by cyphar »

Sanddancer wrote: post #72
cyphar wrote: post #66

Earlier quoted context omitted.

GPL doesn't require copyright assignment (the two issues are completely separate). And if the original author isn't the only copyright holder, they can't make GPL'd code proprietary either. Which is why going GPL is a benefit for everyone -- nobody can effectively make the software proprietary unless there is only a single copyright holder. With BSD-style licenses, everyone is also on an equal footing, except that no…

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 take the existing work of the developers, make a proprietary fork, and convince the developers (in a moment of weakness) to switch and start working on the proprietary code. They can create a new project, but that's always true and not possible to restrict (nor would anyone want to).

> That lock-in effect of the GPL means that your software package can't be used by the larger free software community.

And this is the whole point of the "or any later version" clause. Every complaint you're bringing up has already been resolved by how the GPL is used and has worked for >20 years. Of course the GPL does have its downsides (the whole MPLv1/CDDL thing is a real shame) but "lock-in" is not one of them (unless you explicitly decide to lock yourself in, which is your own fault).

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

#76

Post by ChuckMcM »

ajdlinux wrote: post #64
ChuckMcM wrote: post #59

Earlier quoted context omitted.

I'm guessing (again I can't really test it yet) that it will warn on it and suggest if (int_value != 0) { ... } To be clear about what I mean.

I've just tested against GCC master and can confirm that -Wint-in-bool-context does not trigger on this very, very standard case. Per the examples in the documentation, it does trigger when you do something silly like "if (i In fact if you read the documentation and the warning messages more closely, it's looking for suspicious use of integer constants , not integer variables.

Awesome, and I missed the bit about constants.

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

#77

Post by ckok »

nullc wrote: post #70
Sanddancer wrote: post #56

Earlier quoted context omitted.

I'd argue the opposite, that GPL style licenses make it easier to hide things in black boxes these days. LLVM and Clang are under BSD style licenses, and even Sony has said that being an active contributor keeps things moving along [1] even when they don't have to contribute back. Plus, most BSD-style code doesn't require things like copyright assignment, which can be a big brake against people from contributing back…

> I'd argue the opposite, that GPL style licenses make it easier to hide things in black boxes these days. LLVM and Clang are under BSD style licenses, Where can I download the source code for the specific version of clang used in OSX? (AFAIK, it is unavailable, which has been a bummer in chasing bugs which show up only in it)

Usually they show up here: https://opensource.apple.com

https://opensource.apple.com/release/developer-tools-81.html for example.

Sometimes takes a while to show the latest version though.

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

#78

Post by belorn »

a_t48 wrote: post #73
gribbly wrote: post #46

Earlier quoted context omitted.

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

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.

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

#79

Post by flamedoge »

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

I'm a little mixed about having to run both compilers for more comprehensive result. DRY principle in me tells me that devs could have concentrated effort in one compiler to make it even better.

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

#80

Post by flamedoge »

anon1385 wrote: post #21
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

just curious, why can't one use use-def chains to detect uninitialized variables? Basically you want backward-all dataflow analysis with gen=use & kill=def...
Post reply on HN