GCC 7 Release Series – Changes, New Features, and Fixes | Hacker News Reader

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

gcc.gnu.org

201 pointsrbanffy85 comments

On mainstream native platforms, Ada programs no longer require the stack to be made executable in order to run properly.

What does that even mean? I'm dabbling with Ada as of recently.

Also, woo!

Support for the RISC-V instruction set has been added.

On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also have Clang - all available to me via switch/simple shell functions. I always tend to have my junk work on all of those, so am in a kind of a simplistic position to compare each. From a daily user perspective, there's not much difference at all (clang and newer gcc). Clang's pretty warnings are almost in GCC now as well, speed is still on GCC's side (for me at least) and all is good in GCC and LLVM land. I'm leaning more towards GCC since I've been using it since it became united in late 90s. I believed in it, even though people thought of it, at the time, to be slow and shit. Look at it now! I'm using it on MacOS (yes), Windows and Linux. I'm sure more heavyweight users will find a lot of things GCC can improve upon though.

I know it might not be strictly in the scope of GCC's domain, but I would like to see some static analysis and linters (like MISRA, etc.) included out of the box with it. That would be swell.

http://stackoverflow.com/questions/34982151/executable-ada-c...

>What does that even mean?

I know nothing about Ada but there is a feature called called 'executable bit' in pretty much all desktop processors since 1-2 decades. What this bit does is it marks certain regions of memory as not executable, i.e. you're not allowed to put the instruction pointer onto that region and let the CPU run the instructions. This is a hardware-level feature and can be disabled in BIOS/UEFI. Usually the stack is marked as not executable as a security feature, so buffer overruns can't just write code on the stack and then it is executed.

Why Ada needed this disabled is beyond me. Does it execute things on the stack?

As usual, no-execute bits in the page table is something that trickles down. I think in x86 land AMD introduced it with AMD64. The RISCies (Sparc, Power, Alpha, hppa) had this earlier.

>Why Ada needed this disabled is beyond me. Does it execute things on the stack?

I believe this is due to nested function support. There is some explanation here: https://stackoverflow.com/questions/34982151/executable-ada-...

The static analysis stuff is something that is in clang's favor. Because of its architecture, static analysis is included, and can be run at compile time through a wrapper called scan-build [1]. So, to get static analysis, most of the time, you just have to run "scan-build make" and it'll do things for you. Clang's clang-tidy tool also handles linting as well, with a misra plugin too [2]. That's the big advantage I see with clang, is that its architecture makes a lot of these things a lot easier to add, which is an area that gcc is just barely starting to address.

[1] https://clang-analyzer.llvm.org/scan-build.html

[2] https://github.com/rettichschnidi/clang-tidy-misra

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.

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 anyway and I should be doing more of that.

One claim that everyone will stand by is that the competition between the two has been a huge help.

> 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 discovered several bugs simply by compiling some code with different compilers and running the test suite each time.

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 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 instructions for every (already expensive at that time) function call. Defining unordered evaluation as UB was to avoid having to do temp_a, temp_b, temp_c. Now compiles can do that and trivially optimize that sort of thing out.

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.

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?

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

He meant unspecified behavior. ;)

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.

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

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

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.

They're both very good now. Sometimes the error messages of one are clearer than the other's, sometimes it's the other way around. If I don't immediately find the cause in a long templatey error, I'll just check the other compiler's message. Having both messages can be surprisingly helpful :)

Where clang now clearly leads is in terms of runtime security and debugging features. Both share asan (address sanitizer), ubsan (undefined behavior) and tsan (threads). But msan (memory sanitizer, finds uninitialized memory use) is only available in clang.

In terms of exploit mitigation clang now has control flow integrity and safestack, as far as I'm aware nothing like this is available in gcc.

msan may not be such a big deal, because you could use clang for testing and gcc for production. But I hope more people adopt stronger exploit mitigations like CFI, and if gcc doesn't deliver them clang will win - at least for security sensitive areas.

gcc has ubsan too, and various stack overflow checking mechanisms.

My understanding (and empirical anecdote) is that Clang produces inferior debuginfo (eliding some locals' contents, even when their values are not actually lost) that makes it more difficult to debug than binaries produced by GCC.

asan, ubsan, tsan, and msan are important debugging features, but for my every day use in core analysis, local variables in gdb are very important.

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

There is an important class of warnings which only gcc gets 100% right: Those about optimizing away checks for this != nullptr and &refobject != nullptr (because they will always be true). clang skips the warning inside macros. This is a big problem when you want to find and fix all occurrences before they bite you at runtime.

Many warnings are available in both compilers and effort has been made to use the same names. Both compilers have some warnings exclusively. Clang prefers to raise warnings in the frontend only. Gcc in contrast will sometimes raise more warnings at higher optimization levels. If you can afford the overhead build with clang dbg, gcc O3 and MSVC.

I disagree about warnings inside macros. There are lots of functions like strtod which take an argument and say "if this is non-NULL, store a value into the pointed-to variable", so that you can write "foo(..., &x)" if you want the value and "foo(..., NULL)" if you don't. This is a recipe for a warning which gets disabled due to an excess of false positives.

(I'd say that this warning could be explicitly disabled for the scope is the macro... but alas, GCC broke _Pragma inside macros.)

GCC 7 also removed some boost-specific traits, some of which may impact some libs, like was the case for TBB[1].

[1] - https://github.com/01org/tbb/issues/12

Some of those new warnings look very useful.

Clang really pushed this area forward. Good to see.

  It attempts to move evaluation of expressions executed on all paths to the function *exit* as early as possible, which helps primarily for code size, but can be useful for speed of generated code as well. [Emphasis added.]

Typo? PRE hoists upwards, so it would make sense to move closer to entry, not exit.

Naive question: if you move towards the exit of a function, wouldn't that be beneficial? That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?

The point of hoisting towards entry is to reduce code size, as the changelog indicates. It's safe to hoist the expression from program points P_{0..i..n-1} to some point Q that dominates all P_i if the expression is available at each P_i. That reduces the number of occurrences by n - 1. It's a basic corollary of PRE.

This is identical to what LLVM's load-store motion does for loads, except for all expressions and not just loads.

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

In practice, you want to do both.IE hoist everything you can, sink everything you can.

But not because of "That is, if a function terminates early, you're not evaluating the expressions unnecessarily, no?"

If the function terminates early, and you've moved the expression computation before or after an early termination point, you've by definition changed what paths it is computed on (unless it was already computed there). That is not legal in all cases (it's speculative PRE/PDE)

PRE and VBE (which is what this is) guarantee that the expression is still computed at on the same paths. They just make it so it's computed once.

What is happening here is really a size optimization. If it can prove that it is always executed, it has one copy of the computation, instead of multiple ones.

No, it's correct. It's saying "if they are always computed, we move them up".

  if (a)
    foo = a + b
  else b 
    foo = a + b
  ->
  foo = a+b
  if (a)
  else (b)

How do you move up towards exit?

I think you have to read it like "executed on >all paths to the function exit< as early as possible". As in, if you have an expression that is always executed regardless which path you take before returning. It's useful to move that expression upwards instead of having copies on the different paths to the function exit.

My guess is that they meant "up" in the sense of "up in post dominator tree".

Possible side effects correction:

    ->
      if (a)
      else (b)
      foo = a+b

Sad to see gcj getting the final shot, but the project hasn't changed much since 2009 anyway.

Sigh, looks like one of my common idioms:

   if (int_value) { ... }

Will now be warned/failed.

Hmm, I wonder if that's actually true. I don't have GCC 7 anywhere to actually test it, but the documentation[1] states:

  -Wint-in-bool-context

Warn for suspicious use of integer values where boolean values are expected, such as conditional expressions (?:) using non-boolean integer constants in boolean context, like

  if (a <= b ? 2 : 3)

Or left shifting of signed integers in boolean context, like

  for (a = 0; 1 << a; a++);

Likewise for all kinds of multiplications regardless of the data type. This warning is enabled by `-Wall`.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

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 don't think it will warn for this simple case.

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 < 3 ? 7 : 0)".

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.

Great news on the gccgo front:

> Escape analysis is available for experimental use via the -fgo-optimize-allocs option.

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.

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

Secondly, looking at how GCC development picked up greatly when Clang/LLVM came on stage, it shows that GCC was stagnating with the lack of direct competition, should one of them disappear now, the same thing is likely to happen to the surviving project.

On the contrary, I would prefer having even more competition in this field.

> What I find very strange though is that some people seemingly want one of these projects to die.

I don't think people want, I think people are worried that this will happen. It's pretty clear that commercial backing largely favours LLVM for obvious reasons. A compiler monoculture nobody really wants back.

>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 it enables non-free software. Also obviously it takes away resources that could have gone to improving GCC (although in my opinion a lot of them wouldn't for the reason below). It's an extreme argument, but it's the kind of extreme position Stallman has consistently taken so it's not surprising.

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. i.e. they'd rather software not support something at all if supporting it might benefit non-free software. That's fair enough, but it shouldn't be a surprise when users of the software prefer to use and support a project that isn't deliberately designed to make doing certain tasks very difficult. Academics and other people with an interest in hacking on compilers were obviously going to prefer a project that wasn't architected to try and prevent the very kinds of things they were doing.

The opposition to refactoring tools for emacs based on GCC is the most recent (2015) example of this[2], but the problem is a long standing one. Fundamentally people want to use compilers to do more sophisticated things with their code than just compile it, and that is seen as being incompatible with the political goals of the GCC project.

[1] https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

[2] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... and the rest of that thread

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

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)

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.

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.

That's what you get when you prefer programs that are merely open source to free software.

LLVM is free software. The term you are looking for is "copyleft".

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

I wish people, particularly devs, thought more about licenses and their long term impact on freedom of the user & dev. I get tired of hearing about how "but copyleft is less free because it restricts me", but to me that's like saying "individual liberty under the rule of law is less free because it prevents me from punching that dude in the face". It's some strange form of anarchism argumentation that fails to respect the rights of others.

With all the security issues cropping up lately, I think it should be obvious to big picture thinkers that, while not the solution in itself, any real forward thinking solutions for cyber-security must focus on keeping black boxes out of the picture. BSD style licenses are dangerous to me because they allow hard working peoples code to be abused and used for abuse of others.

To be fair to this particular argument though, LLVM does fall under the LSCA license which is gpl compatible, it simple isn't copyleft, so my above rant is more a general comment than on the topic of clang.

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

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

If every free software project was copylefted, it would be effectively impossible for any company that is smaller than Apple to maintain everything they need to make software proprietary. Want font rendering? Reimplement libharfbuzz. Want to write any C program? Reimplement glibc. And so on.

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

Only if they have a CLA or don't accept any contributions. I can't think of any examples of such AGPL projects, but even with the GPL such projects are quite rare (and CLAs like the FSF actually don't allow them to create proprietary forks). You're just spreading FUD, please stop.

>it would be effectively impossible for any company that is smaller than Apple to maintain everything they need to make software proprietary.

Why does it need to be proprietary in the first place though. I feel like the arguments I am hearing are making assumptions about the desired outcome to support their reasoning.

Sorry, I don't think my tone was clear. It's a good thing that it would make proprietary software effectively impossible to maintain (I'm a huge proponent of both copyleft and free software). I completely agree with your GP comment. ;)

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.

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.

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

Why make it easier for them? Very few companies can be like Apple (and even Apple didn't write everything from scratch). Compromising allows more companies to wrong their users, it's not helpful to treat companies like people -- without a profit motive most companies won't liberate their software.

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.

Additionally, a lot of GPL software, like MySQL and BerkeleyDB, create a more closed community because that company has a lot more ability to create their own black box projects through dual licensing as closed source works. Postgres, in comparison, is BSD licensed, making it much harder for a company like Oracle to buy out pieces of the community and run away with the source and make deals others can't. The GPL has a lot less community power to counter those sorts of situations.

[1] http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain....

Both MySQL and BDB require either copyright assignment or a CLA.

In contrast, Linux does not and GCC's FSF copyright assignment includes a promise that the software will remain free.

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 now users have no guarantees that the software they use will be maintained as free software. At any point, a treacherous developer or company could scoop up the talent from the community and make a maintained fork of the project proprietary. The original project dies because of lack of talent and now free software has helped expand the reach of proprietary software.

Note that even with copyright assignments, there are some good ones. The FSFs (optional for projects) copyright assignment has specific wording that guarantees they will always keep the code free (and even go further to state that it will always be copyleft and in keeping with their well-documented philosophy). If I had a single foundation I had to pick to assign my copyright to, it would be the FSF.

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.

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

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.

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

Open-source means the exact same thing as free software, there's just an ideological difference between the two.

https://opensource.org/osd

It definitely does not mean the same thing, the OSD is not congruent to the four freedoms. They have significant overlap, but they are not equal sets.[1]

As a dumb example, the Open Watcom license is an "open source" license but is not a free software license because it is too restrictive. In the Open Watcom instance, the OSD does not protect the freedom for users to have private copies of software, the four freedoms do (or at least the modern interpretation does).

There's also the whole TiVo thing, where the modern interpretation of freedom 0 is restricted by DRM while "open source" software does not have any problems with DRM restricting users.

[1]: https://www.gnu.org/philosophy/open-source-misses-the-point....

It's more at risk because they have lost sight of what people want. Firefox muddled itself with a halfassed phone project, a programming language, etc, instead of making a good browser, while google poured efforts into making chrome fast and less prone to crashes taking out everything. It's only natural then that they'd lose market share. Free isn't Good Enough, it has to work well too.

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

Reply on news.ycombinator.com