Linked by Thom Holwerda on Wed 15th Jun 2011 14:23 UTC, submitted by Valhalla
General Development "PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers." More here.
Order by: Score:
How fast could i make my code:
by judgen on Wed 15th Jun 2011 14:58 UTC
judgen
Member since:
2006-07-12

How fast can i convert the code i have made for compilation with GCC tools. What benefits would i get when using this compiler. Would binaries made with this software be in any legal danger if it is licensed under a different license than the compiler tools?

Lots more of questions i guess, but lastly what would be the performance when using EKOPath compared to GCC when using a small/medium/large code base?

Reply Score: 2

RE: How fast could i make my code:
by plenque on Wed 15th Jun 2011 15:05 UTC in reply to "How fast could i make my code:"
plenque Member since:
2005-10-10

Some of your questions are answered in the linked article.... I think all of them in the forums at Phoronix.

Reply Score: 1

judgen Member since:
2006-07-12

Ok i will look into it more deeply. Thank you.

EDIT: Will the suite make for faster binaries? That i could not find a definite answer for on phoronix.

Edited 2011-06-15 15:18 UTC

Reply Score: 2

ciplogic Member since:
2006-12-22

As most modern compilers, they know to optimize patterns, sometimes with a wider applicability or lesser one.
EkoPath is optimized for HPC workloads (similar with Intel Compiler to one level) and for Amd64 bit only, meaning that they had in some cases opportunities to make the best code.
So at the end: if you have tight scientific code there will be a visible at least 20% speedup over GCC. Also the runtime have more optimized runtime methods, so if the application will use them, can see more benefits, but who knows!?
At the end, will a distro recompile everything to EkoPath? I think that is unlikely: the binaries are a bit bigger as far as I've sow and the speed is not obtained most likely just from this. Will a browser vendor recompile their products to obtain a bit faster layouting? Maybe.
At the end I think you will simply win if you will have to render a thing for a week and worth the price to recompile the raytracer to finish if things will work smooth in 5 days, and one day of you will be free.

Reply Score: 2

Valhalla Member since:
2006-01-24


So at the end: if you have tight scientific code there will be a visible at least 20% speedup over GCC.free.

Whoa, let's not make such sweeping statements shall we, even in the very small current Phoronix testbed there's a benchmark where ekopath loses out to gcc 4.5 (which is what it was benchmarked against). That said, judging by most of the benchmarks there's potentially alot of performance to be had from this specifically Intel/AMD 64-bit targeted compiler suite.

Also hoping it will have alot better GCC compability than ICC had last time I tried it.

For those of us with Intel/AMD 64-bit systems there could be alot of performance to be had in heavily computational applications, and Pathscale is obviously very set on keeping the bar high, given that ekopath failing to beat GCC or any other compiler in performance is considered a bug by Pathscale.

Gentoo ricers, mount up! ;)

Reply Score: 4

Elv13 Member since:
2006-06-12

/etc/portage/packages.compiler

Reply Score: 2

CodeMonkey Member since:
2005-09-22

Will the suite make for faster binaries? That i could not find a definite answer for on phoronix.


I've been maintaining the LAPACK build and test infrastructure for ~ 6mo now and we've seen great performance numbers out of the PathScale compilers. Typical runtimes for the LAPACK test suite running 4 tests in parallel for 98 tests (this is on a 2 year old quad core xeon):

GNU Fortran : 1.5 min.
Intel Fortran : 0.7 min.
PGI Fortran : 0.7 min.
PathScale Fortran : 0.4 min.

I was blown away by it myself and almost didn't beleive it. I've seen comparable results with other C++ code bases. There are many contributing factors to the performance of your code (often HPC code will depend heavily on an optimized math library) and everybody's codebase and workload is different, but speaking from experience, for math intensive code the PathScale compiler is really top notch.

Reply Score: 5

Alfman Member since:
2011-01-28

CodeMonkey,

"I was blown away by it myself and almost didn't beleive it. I've seen comparable results with other C++ code bases."

If this is true, I'll need to take a look into it.

I downloaded the trial, but it wouldn't run on this 32bit system (silly me).

Unfortunately I cannot afford the price "Starting at $1795", which is a yearly price?

Like everyone else, I didn't find any open source code. Technically they might not distribute the source code to non-customers.

Does anyone know what they mean by "open source"? The following statement gives me the impression they're not going to use GPL3 for the debugger or the compiler.

"In addition to the compiler, this release also includes PathDB, a modern debugger. PathDB has been released under a permissive license, in response to requests from the open source community for a modern debugger that is not encumbered by the GPLv3."

I hate speculating, does anyone know the details?

Reply Score: 2

Valhalla Member since:
2006-01-24


Like everyone else, I didn't find any open source code. Technically they might not distribute the source code to non-customers.

https://github.com/path64/repositories

AFAIK these are the source code repositories for path64 compiler and debugger. However, unless I'm mistaken not all proprietary path64 features has yet been added to this repo but they will be (it's after all the whole point of this announcement).

Meanwhile you can try out prebuilt nightlies from the homepage: http://www.pathscale.com/ekopath-compiler-suite


Does anyone know what they mean by "open source"? The following statement gives me the impression they're not going to use GPL3 for the debugger or the compiler.

The compiler suite is open sourced under GPLv3, the debugger is released under BSD (same goes for their libcxx runtime).

Reply Score: 5

codestr0m Member since:
2011-06-16

The debugger is CDDL and there's two github accounts to watch.

github.com/path64
github.com/pathscale

The runtimes are at the pathscale account. We're in the process of also pushing the developer documentation, assembler and some build glue soon.

Reply Score: 2

pabloski Member since:
2009-09-28

No, there's the code and the binaries too http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-4....

The compiler and runtime libraries have been released under gplv3.

If the compiler gives an error about crt1.0, you just need to create a symlink /usr/lib64 who points to /usr/lib

Reply Score: 1

Alfman Member since:
2011-01-28

pabloski,

"No, there's the code and the binaries too http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-4...... "

Thanks,

I was looking for the source separately and didn't realize it was packaged in the 64bit executable. I'll have to wait until I get to a 64bit linux system to look at it. There's github in the meantime.

Edited 2011-06-16 11:24 UTC

Reply Score: 2

CodeMonkey Member since:
2005-09-22

Like everyone else, I didn't find any open source code.

When the announcement was made they didn't have code published yet. According to PathScale it should be ready "soon". I believe it will first be on thier website and then pushed to github (not path64 on github, no further commits will be made there).

Technically they might not distribute the source code to non-customers.

About 6 months ago I reached out to PathScale along with several other compiler vendors. I asked if they'd be willing to donate a license to thier compiler for use with the LAPACK project and it's nightly build and test infrastructure. So I wasn't a customer but they were will to help support the open source community and did in fact donate a license to us.

Reply Score: 2

Valhalla Member since:
2006-01-24


GNU Fortran : 1.5 min.
Intel Fortran : 0.7 min.
PGI Fortran : 0.7 min.
PathScale Fortran : 0.4 min.

I was blown away by it myself and almost didn't beleive it. I've seen comparable results with other C++ code bases.

Wow, that is good.

(often HPC code will depend heavily on an optimized math library) and everybody's codebase and workload is different,

Yes we've joked about that in development, compiler benchmarking (and even language benchmarking) in many cases end up being a comparison of which one comes with the most optimized math lib for your particular platform.

Reply Score: 2

kargl Member since:
2007-10-16

Your timings are meaningless without details!
What compiler versions? What compiler options?
Is this wall-clock or cpu-time?

With pathf95, built from today sources, I
cannot compile lapack from netlib without
hitting an internal compiler error. This,
of course, means that the execution time
of any lapack benchmark cannot be obtained.

Reply Score: 1

CodeMonkey Member since:
2005-09-22

Is this wall-clock or cpu-time?

Wall clock time

Your timings are meaningless without details!
What compiler versions? What compiler options?

These weren't with super aggressive optimizations but with "safe" optimizations. Trying to do things like -Ofast on most compilers will often break the numerical accuracy of the LAPACK code so anything over O2 is recommended to be avoided.
gfortran 4.4.0 : -O2 -march=native
ifort 12.0 : -O2 -xHost
pgif90 13.1 : -O2 (pgi does the equiv. of march=native by default)
pathf90 4.0.10 : -O2 -march=native

With pathf95, built from today sources, I
cannot compile lapack from netlib without
hitting an internal compiler error.

Perhaps an issue to take up with PathScale and your particular setup but two of the nightly LAPACK svn builds are with the previously linked to 4.0.10 nightly build from 2 days ago.

This, of course, means that the execution time of any lapack benchmark cannot be obtained.

Please note that this is not designed to be a benchmark but simply the test suite for the code base. It was just one example of code that I've seen and worked with that shows great gains from the PathScale compiler.

And for those who might be wondering, this is not using an optimized BLAS imlementation but instead the netlib fortran BLAS was built as part of the LAPACK build. On larger datasets and matricies building against an optimized BLAS (like goto, atlas, mkl, or acml) can make a big difference but for the small data sizes in the software test suite the difference is not significant.

Reply Score: 2

RE: How fast could i make my code:
by lemur2 on Thu 16th Jun 2011 02:30 UTC in reply to "How fast could i make my code:"
lemur2 Member since:
2007-02-17

Would binaries made with this software be in any legal danger if it is licensed under a different license than the compiler tools?


As with all GPL programs, the GPL license and the associated copyleft provisions apply to the source code of the (GPL'd) program itself (in this case, the GPL applies to the source code of the EKOPath 4 Compiler Suite). You have unlimited, irrevocable, unconditional permission (under the GPL) to use (as in run it) such a program however, wherever and whenever you wish, for any purpose. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools to other people.

Whatever source code you write is your code, to license as you please. It matters not one whit that you used a particular compiler to compile that code (just as it matters not one whit what particular text editor you used), if you wrote the source code you are still the author, and the copyrights to your source code belong to you. What you do with your code is not at all constrained by the GPL unless you choose to release your code under the GPL.

Edited 2011-06-16 02:37 UTC

Reply Score: 3

GPL compiler with non-GPL code?
by Alfman on Thu 16th Jun 2011 03:05 UTC in reply to "RE: How fast could i make my code:"
Alfman Member since:
2011-01-28

lemur2,

"As with all GPL programs, the GPL license and the associated copyleft applies to the source code of the program. Youy have unlimited, irrevocable, unconditional permission (under the GPL) to use the program however you wish. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools."

Hmm, I don't know if that's right. The binary could arguably be a derivative work.

I think the FSF uses a different interpretation of the GPL than common sense might infer, which is why they've licensed GCC with GPL exceptions.

http://www.gnu.org/licenses/gcc-exception-faq.html

In the faq, read this section "Why is compiler intermediate representation excluded from the definition of 'Target Code?'"

"...If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL."


It's pretty clear that the FSF intends GCC compiled code not covered by the exception to fall under the GPL license.


If the FSF interpretation of the GPL is accurate (it would be ironic if it wasn't), then in theory a GPL compiler without exceptions can only be used for GPL projects.


Edit:
Personally I find this interpretation bizarre. At the extreme, there could be license ramifications for all GPL tools like 'sed' or 'grep' lacking explicit exceptions.

Of course I leave it to the capable hands of more knowledgeable posters to explain it to me.

Edited 2011-06-16 03:12 UTC

Reply Score: 2

RE: GPL compiler with non-GPL code?
by lemur2 on Thu 16th Jun 2011 03:35 UTC in reply to "GPL compiler with non-GPL code?"
lemur2 Member since:
2007-02-17

lemur2, "As with all GPL programs, the GPL license and the associated copyleft applies to the source code of the program. Youy have unlimited, irrevocable, unconditional permission (under the GPL) to use the program however you wish. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools." Hmm, I don't know if that's right. The binary could arguably be a derivative work. I think the FSF uses a different interpretation of the GPL than common sense might infer, which is why they've licensed GCC with GPL exceptions. http://www.gnu.org/licenses/gcc-exception-faq.html In the faq, read this section "Why is compiler intermediate representation excluded from the definition of 'Target Code?'" "...If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL." It's pretty clear that the FSF intends GCC compiled code not covered by the exception to fall under the GPL license. If the FSF interpretation of the GPL is accurate (it would be ironic if it wasn't), then in theory a GPL compiler without exceptions can only be used for GPL projects. Edit: Personally I find this interpretation bizarre. At the extreme, there could be license ramifications for all GPL tools like 'sed' or 'grep' lacking explicit exceptions. Of course I leave it to the capable hands of more knowledgeable posters to explain it to me.


The definition of "derivative work" comes from copyright law, not from the FSF. Copyright law itself is the law, not whatever the FSF says or thinks, or is thought to say or think.

http://en.wikipedia.org/wiki/Derivative_work

"In United States copyright law, a derivative work is an expressive creation that includes major, copyright-protected elements of an original, previously created first work."


Unless your work actually INCLUDES pieces of some other work, it simply is not a derived work under copyright law. In addition, it has to INCLUDE "major elements" of another work ... mere snippets is not enough, nor is non-functional references.

This is why dynamic linking is not an issue ... with dynamic linking the linked code is not actually included, merely referenced. Only static linking actually includes external code to be distributed within another work.

So, in the case of the "EKOPath 4 Compiler Suite", unless your source code actually, literally, INCLUDES (perhaps via via static linking or by direct copy-and-paste) some "major element" of the "EKOPath 4 Compiler Suite" source code, then your work is simply not affected by the license of the "EKOPath 4 Compiler Suite" source code, under copyright law.

That is the law, no matter what the FSF might say or think.

Just as the license for a text editor program has no bearing on the ownership rights of the text one edits using it as long as one doesn't include the source code of the editor, so too does the license of the "EKOPath 4 Compiler Suite" have absolutely nothing to do with the rights to the code compiled with it, unless one includes some major element of the source code of the "EKOPath 4 Compiler Suite" itself.

Edited 2011-06-16 03:44 UTC

Reply Score: 3

lemur2 Member since:
2007-02-17

It's pretty clear that the FSF intends GCC compiled code not covered by the exception to fall under the GPL license. If the FSF interpretation of the GPL is accurate (it would be ironic if it wasn't), then in theory a GPL compiler without exceptions can only be used for GPL projects.


Apart from the fact that the intentions of the FSF have no bearing on copyright law itself, it is also pertinent to note that while the FSF's has claims over GCC source code, despite being the original authors of the GPL license template text the FSF does NOT in fact have claims over "EKOPath 4 Compiler Suite" source code.

So the only sane conclusion from this observation is that whatever the FSF might believe in this scenario is DOUBLY irrelevant.

Reply Score: 3

Alfman Member since:
2011-01-28

lemur2,

"So the only sane conclusion from this observation is that whatever the FSF might believe in this scenario is DOUBLY irrelevant."


I didn't mean to imply the FSF has any say over EKOPath. If PathScale took the same stance as the FSF but uses the GPL without exceptions, it could be their intent that the open source EKOPath should only be used for GPL code.

I agree it sounds ridiculous, but your earlier post made it sound like you weren't aware of the exceptions for GCC, which is why I brought them up.

Edited 2011-06-16 04:33 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

lemur2, "So the only sane conclusion from this observation is that whatever the FSF might believe in this scenario is DOUBLY irrelevant." I didn't mean to imply the FSF has any say over EKOPath. If PathScale took the same stance as the FSF but uses the GPL without exceptions, it could be their intent that the open source EKOPath should only be used for GPL code. I agree it sounds ridiculous, but your earlier post made it sound like you weren't aware of the exceptions for GCC, which is why I brought them up.


Here is the actual opinion of the FSF on this topic, in their own words, without any agenda-driven interpretations on top of it:

http://www.gnu.org/licenses/gpl-faq.html#DoesUsingTheGPLForAProgram...
Q: Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?

A: Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.


The FSF opinion in relation to the copyright law requirement that a derived work results only when a major element of an original work is INCLUDED in another work:

Q: Do I have “fair use” rights in using the source code of a GPL-covered program?

A: Yes, you do. “Fair use” is use that is allowed without any special permission. Since you don't need the developers' permission for such use, you can do it regardless of what the developers said about it—in the license or elsewhere, whether that license be the GNU GPL or any other free software license.


QED. It turns out that the FSF do indeed understand copyright law, and it is only you who is confused.

Your references are now TRIPLY irrelevant to the original question. (PathScale's views are only SINGLY irrelevant).

You are utterly incorrect on this topic, not only according to copyright law itself, but also according to the FSF.

Edited 2011-06-16 04:54 UTC

Reply Score: 4

lemur2 Member since:
2007-02-17

Your references are now TRIPLY irrelevant to the original question. (PathScale's views are only SINGLY irrelevant).


Sorry, I should have expressed that differently.

It should have read as follows:
"Your mistaken interpretation of FSF's views on this topic are now TRIPLY irrelevant to the original question. PathScale's views, whatever they may be, are only SINGLY irrelevant."

Reply Score: 2

Alfman Member since:
2011-01-28

lemur2,

"Q: Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?

A: Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code."


The answer above is (apparently) referring to this snippet:

"The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does."


So it's clear cut for editors, but it's not so obviously simple for things like compilers.


"Q: Do I have “fair use” rights in using the source code of a GPL-covered program?

A: Yes, you do. 'Fair use' is use that is allowed without any special permission. Since you don't need the developers' permission for such use, you can do it regardless of what the developers said about it—in the license or elsewhere, whether that license be the GNU GPL or any other free software license."


No copyright holder can restrict fair use rights, but I don't see how this is at all relevant to this discussion? Are you suggesting that we have a fair use right to use GCC without a license? I really don't understand what you are getting at.

"QED. It turns out that the FSF do indeed understand copyright law, and it is only you who is confused."

Perhaps I am, but I brought up relevant points, and it appears that you are no less confused than I am.


"Your references are now TRIPLY irrelevant to the original question. You are utterly incorrect on this topic, not only according to copyright law itself, but also according to the FSF."

Wow...what did I trigger to make you lash out like this? While you were counting irrelevant levels of irrelevance, I think you forgot to ponder why the FSF has GPL exceptions for GCC.

Reply Score: 2

Alfman Member since:
2011-01-28

lemur2,

"The definition of 'derivative work' comes from copyright law, not from the FSF. Copyright law itself is the law, not whatever the FSF says or thinks, or is thought to say or think."

Then maybe that's why they got rid of the terminology "derivative work" and replaced it with "covered work" in gpl3.


Hypothetically, MS could release a free educational edition of MS-Word which was only to be used for public domain educational research papers under a license which explicitly revokes the rights for any other use.

Do think someone could obtain MS-Word under this license and legally claim that they're entitled to use Word for private/commercial work when they get caught?

If not, then how the GCC case different?

Keep in mind that both the GPL2/3 revoke rights in this manor.


GPL2:

7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.

GPL3:

12. No Surrender of Others' Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

Reply Score: 2

cmchittom Member since:
2011-03-18

Then maybe that's why they got rid of the terminology "derivative work" and replaced it with "covered work" in gpl3.


No, those are two different (though sometimes related) things. A "derivative work" is, as has already been mentioned, defined in copyright law. A "covered work" is a work "covered" by a particular license (GPL3 in this case). A derivative work of a GPL3 covered work would also be a covered work. But a derivative work of a BSD-licensed covered work might or might not be a covered work.

Hypothetically, MS could release a free educational edition of MS-Word which was only to be used for public domain educational research papers under a license which explicitly revokes the rights for any other use. Do think someone could obtain MS-Word under this license and legally claim that they're entitled to use Word for private/commercial work when they get caught? If not, then how the GCC case different? Keep in mind that both the GPL2/3 revoke rights in this manor.


Hypothetically, Microsoft could do that, yes. The cases are different because that's not what the GPL says. Again: "derivative work" is a legal term explicitly defined in copyright law.

Reply Score: 1

Alfman Member since:
2011-01-28

cmchittom,

"Hypothetically, Microsoft could do that, yes. The cases are different because that's not what the GPL says. Again: 'derivative work' is a legal term explicitly defined in copyright law."

I don't know if I want to touch this again, but this is mixing up two separate points. The fact that our documents are not derived from MS sources has no bearing on whether MS can legally specify the types of documents we are permitted to work on under a public/educational Word license.

In the same vein, a visual studio license would have the right to limit our use to non-commercial code, regardless of whether our source code is legally derived from anyone else's.

Edited 2011-06-16 14:27 UTC

Reply Score: 3

boldingd Member since:
2009-02-19

lemur2,

"As with all GPL programs, the GPL license and the associated copyleft applies to the source code of the program. Youy have unlimited, irrevocable, unconditional permission (under the GPL) to use the program however you wish. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools."

Hmm, I don't know if that's right. The binary could arguably be a derivative work.


It's not. This is an old question, with an old answer. Compiled binaries are not derivative works; anything you create with a GPL'ed tool is yours to do with as you please (as is true with any other GPL'ed program that produces something, like the GIMP).

I think the FSF uses a different interpretation of the GPL than common sense might infer, which is why they've licensed GCC with GPL exceptions.

http://www.gnu.org/licenses/gcc-exception-faq.html

In the faq, read this section "Why is compiler intermediate representation excluded from the definition of 'Target Code?'"

"...If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL."


Let me include the whole FAQ entry in question:

Why is compiler intermediate representation excluded from the definition of “Target Code?”

When we first considered adding a plugin infrastructure to GCC, we were deeply concerned about the possibility that someone would write a plugin that would merely save GCC's internal, low-level compilation data structures to disk. With that done, other software would be able to optimize or otherwise improve that code without being directly connected to GCC. It may have been difficult for us to argue that those programs should be subject to the GPL's copyleft, so we wanted to discourage these sorts of arrangements.

We do that by excluding such output from the definition of Target Code. Because of this, even if someone writes a plugin that saves this information to disk, any programs that change the structures before GCC writes out Target Code will be involved in the Compilation Process. If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL.


What they're specifically talking about here is preventing some "clever" third party from using GCC's plug-in architecture to attempt to circumvent the GPL license covering GCC. Basically, if you use a plug-in to operate on the low-level in-memory structures that GCC is using to compile your code, you don't get the license exception that allows you to include the technically-GPL'ed trivial libraries that GCC is going to link your code with under other licenses. This has no effect on normal use of the compiler.

It's pretty clear that the FSF intends GCC compiled code not covered by the exception to fall under the GPL license.


You really had to torture your reading of that page to get to that conclusion. The very first two paragraphs specifically state that the GCC developers have always intended to support proprietary development, even if they don't particularly like it. The second and third paragraphs of your own link:
The licenses for some libraries that accompany GCC have not been changed yet. These libraries are automatically used by the object code that GCC produces. Because of that, if these libraries were simply distributed only under the terms of the GPL, all the object code that GCC produces would have to be distributed under the same terms. However, the FSF decided long ago to allow developers to use GCC's libraries to compile any program, regardless of its license. Developing nonfree software is not good for society, and we have no obligation to make it easier. We decided to permit this because forbidding it seemed likely to backfire, and because using small libraries to limit the use of GCC seemed like the tail wagging the dog.

Therefore, these libraries have always had license exceptions that allow people to distribute the object code GCC produces under any license.
We are now moving these libraries to GPLv3 and updating their exceptions. Our fundamental policy has not changed; the new license is meant to permit all the uses of GCC that were permitted before. However, we have decided to use this opportunity to update the exception to accomplish three goals:

My Bold.

So, first, it is definitely legal to distribute binaries built with GCC under any license, and it is definitely the FSF's intention that that be the case. Second, that page is in its entirety about including license exceptions for "small, trivial libraries" that GCC automatically links into compiled object files specifically so that they can be distributed under proprietary licenses.

If the FSF interpretation of the GPL is accurate (it would be ironic if it wasn't), then in theory a GPL compiler without exceptions can only be used for GPL projects.


Edit:
Personally I find this interpretation bizarre. At the extreme, there could be license ramifications for all GPL tools like 'sed' or 'grep' lacking explicit exceptions.

Of course I leave it to the capable hands of more knowledgeable posters to explain it to me.


The FSF isn't claiming that the GCC's license applies to code that it generates. That isn't how "derived work" has ever been understood to be defined. What they're saying is that GCC links trivial libraries into the object code that it generates, and that those are covered by the GPL; that's where the "GPL infection" is coming from. Exactly because they felt like it would be inappropriate to force the GPL onto any object file built with the GPL, they included exceptions in the license of those trivial libraries allowing them to be included in proprietary programs.

Reply Score: 2

Alfman Member since:
2011-01-28

boldingd,

Thank you for trying to understand my points and putting them in the context they needed. I very much appreciate your candid response minus the arrogance and down speaking.

I agree with your conclusion that the FSF wants GCC to compile code under any license.

The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.

Edited 2011-06-17 20:45 UTC

Reply Score: 2

boldingd Member since:
2009-02-19

The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.


The reason an exception is needed is because some "trivial libraries" that are covered by the GPL are automatically linked into compiled code. As to why not use the LGPL, I don't know for sure, but my best guess is that the LGPL only allows dynamic linking, whereas what we're talking about sounds more like static linking -- inserting the compiled form of these trivial libraries directly into the resulting executable. The LGPL (IIRC) doesn't allow that (without an exception).

Reply Score: 2

lemur2 Member since:
2007-02-17

"The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.


The reason an exception is needed is because some "trivial libraries" that are covered by the GPL are automatically linked into compiled code. As to why not use the LGPL, I don't know for sure, but my best guess is that the LGPL only allows dynamic linking, whereas what we're talking about sounds more like static linking -- inserting the compiled form of these trivial libraries directly into the resulting executable. The LGPL (IIRC) doesn't allow that (without an exception).
"

Copyright law itself says differently. Copyright law says that a later work is a derivative work of an earlier work only when the later work INCLUDES MAJOR ELEMENTS of the earlier work.

Since dynamic linking means that the linked code is not actually included in the distributed code of the later work, under copyright law itself dynamic linking is never a problem.

If you think about it, dynamic linking is no different in essence to calling an OS function anyway. All programs must call OS functions, yet they are not derived works, as they do not actually INCLUDE those OS functions within themselves. Apart from the mechanisms used to invoke the functions, how is dynamic linking any different in principle from this?

With static linked code, however, that code is indeed INCLUDED in the programs that link it in. One needs LGPL-like exemptions in order to static link to someone else's code. The exemptions provide the permissions to use the code in this way under copyright law.

The GCC exemptions are provided only to make it EXPLICITLY clear that the GPL copyleft of the compiler itself does not apply to the programs compiled with it. Under copyright law this is the case anyway (because no MAJOR ELEMENTS of GCC itself are INCLUDED into the compiled binaries), but the GCC developers did not want for people to have to rely on that, they wanted to make it explicitly clear.

Reply Score: 2

lemur2 Member since:
2007-02-17

The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.


This question has already been asked, and answered. The small libraries included by GCC into compiled works are not major elements of GCC, and so the works compiled by GCC are not derived works of GCC, under the definitions in copyright law.

However, the authors of GCC did not want users of GCC to have to rely on this, it would likely be seen by some people as tenuous and indirect. Detractors of free software could spread doubt about using GCC.

Far better to simply say, straight out right there in the GCC license itself, that these small libraries are exempt. Then no-one could possibly have any doubts about them.

Edited 2011-06-18 10:26 UTC

Reply Score: 2

Alfman Member since:
2011-01-28

lemur2,

You are saying what you want to hear, rather than what's true.

What the heck, if it makes you feel any better, I say you're right about everything. Enjoy your weekend.

Edited 2011-06-18 11:07 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

lemur2,

You are saying what you want to hear, rather than what's true.

What the heck, if it makes you feel any better, I say you're right about everything. Enjoy your weekend.


I have said nothing at all untrue.

Copyright law says what it says, I am not making it up.

I offered you a perfectly reasonable, obvious, sensible explanation of why the license for GCC includes exemptions for small libraries, even though these exemptions are not required by copyright law itself.

It makes perfect sense.

You have got nothing. Hence your reply.

Have a good weekend yourself.

Reply Score: 2

wide ranging oss performance uplift
by project_2501 on Wed 15th Jun 2011 15:24 UTC
project_2501
Member since:
2006-03-20

Image the impact of this on future Linux/BSD distributions, server software, desktop software, usability, ... it will be a step change upwards that the competition will face.

I'm looking forward to faster web application servers, faster encoding, smoother and snappier desktops, quicker bootups, ... everything really should see an uplift.

Reply Score: 4

coreyography Member since:
2009-03-06

Not sure how much impact it (the compiler, not the C++ library) is going to have on the BSDs, since it is GPL licensed. The viewpoint on licensing of the system compiler seems to vary among the BSD camps, but I suspect at some level they'd all like to see something BSD (or compatible) licensed.

That said, options are always good. The performance with this may overcome some people's philosophical objections to its license.

Reply Score: 1

JAlexoid Member since:
2009-05-19

So.... Aren't BSDs already compiled by a GPL GCC?

Edited 2011-06-15 22:13 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

Not sure how much impact it (the compiler, not the C++ library) is going to have on the BSDs, since it is GPL licensed. The viewpoint on licensing of the system compiler seems to vary among the BSD camps, but I suspect at some level they'd all like to see something BSD (or compatible) licensed. That said, options are always good. The performance with this may overcome some people's philosophical objections to its license.


You do not need a BSD-licensed compiler to compile BSD.

This is the same deal as for books, in that the exact same copyright laws apply. You can write a book using MS Office, but even in doing so all rights to the book itself still belong to you, and not to Microsoft. Your work is still your work, no matter who made the tools that enabled you to do your work.

Reply Score: 3

lucas_maximus Member since:
2009-08-18

However the BSDs do not like non-BSD licensed software in their codebases (OpenBSD especially), therefore they try to exclude GPL licensed code ... the PCC project in regards to OpenBSD is a good example.

Reply Score: 2

lemur2 Member since:
2007-02-17

However the BSDs do not like non-BSD licensed software in their codebases (OpenBSD especially), therefore they try to exclude GPL licensed code ... the PCC project in regards to OpenBSD is a good example.


This means only that because of its GPL license the open source EKOPath4 compiler itself would itself not be chosen by BSD distributions as the included compiler.

I agree.

That does not mean that what I said was incorrect. It still remains true to say that:
You do not need a BSD-licensed compiler to compile BSD.


There is no requirement that you compile BSD-licensed code on a BSD system.

Edited 2011-06-16 23:20 UTC

Reply Score: 2

lucas_maximus Member since:
2009-08-18

That does not mean that what I said was incorrect. It still remains true to say that:


Didn't say it was ... I was merely stating that I don't expect the BSDs to use this because of the license. Also I also suspect it probably doesn't run on all the platforms that they support ... i.e. m68k, SPARC, SPARC64. So I would imagine that this would end up being distributed as a optional component i.e. a package.

There is no requirement that you compile BSD-licensed code on a BSD system.


I know.

Reply Score: 2

lemur2 Member since:
2007-02-17

"That does not mean that what I said was incorrect. It still remains true to say that:


Didn't say it was ... I was merely stating that I don't expect the BSDs to use this because of the license. Also I also suspect it probably doesn't run on all the platforms that they support ... i.e. m68k, SPARC, SPARC64. So I would imagine that this would end up being distributed as a optional component i.e. a package.

There is no requirement that you compile BSD-licensed code on a BSD system.


I know.
"

If it is possible to use a compiler for 64-bit the x86_64 architecture which gives a considerable performance boost, why wouldn't the BSD developers use it to build their BSD distribution? What exactly would be their problem?

As I understand it, BSD distributions have even shipped GCC in the past, which is GPL-licensed. Surely not using a good option for one of your supported platforms such as the EKOPath 4 compiler (even if you don't ship it) just because it has a GPL license is simply a rather obvious case of cutting your nose to spite your face.

Edited 2011-06-17 11:00 UTC

Reply Score: 2

lucas_maximus Member since:
2009-08-18

If it is possible to use a compiler for 64-bit the x86_64 architecture which gives a considerable performance boost, why wouldn't the BSD developers use it to build their BSD distribution? What exactly would be their problem?


I dunno about NetBSD or FreeBSD ... but with OpenBSD the idea of for pcc was faster compile times so times between testing could be reduced.

As I understand it, BSD distributions have even shipped GCC in the past, which is GPL-licensed. Surely not using a good option for one of your supported platforms such as the EKOPath 4 compiler (even if you don't ship it) just because it has a GPL license is simply a rather obvious case of cutting your nose to spite your face.


I am a web dev so a lot of this stuff goes over my head ... however I believe this

http://www.informit.com/articles/article.aspx?p=1168313&seqNum=1

may answer some of your questions.

I think this is important though,

"Having to support only a single compiler can reduce development costs, however."

BSDs have less developer resources and I think having one compiler for the source tree that works on all target archs and is less complex compiler is a benefit.

Edited 2011-06-17 12:07 UTC

Reply Score: 2

Am I missing something?
by e_val on Wed 15th Jun 2011 18:40 UTC
e_val
Member since:
2005-11-02

Open-sourcing the suite is definitively great and welcome step from PathScale. But where do I find the sources or at least a download link for EKOPath 4? The only link on product page is for nightly build, which is a binary installer with (presumably) some non-free components, as its license dialog suggests.

I'm not a free software zealot, but just trying to understand: is it only PR for now, or the code is actually released?

Thanks for hints.

Reply Score: 1

RE: Am I missing something?
by Bill Shooter of Bul on Wed 15th Jun 2011 18:51 UTC in reply to "Am I missing something?"
Bill Shooter of Bul Member since:
2006-07-14

Thanks for hints.


The thirsty red chicken walks at midnight with a broken cane.

Reply Score: 4

RE[2]: Am I missing something?
by adkilla on Thu 16th Jun 2011 15:47 UTC in reply to "RE: Am I missing something?"
adkilla Member since:
2005-07-07
RE: Am I missing something?
by shmerl on Wed 15th Jun 2011 19:35 UTC in reply to "Am I missing something?"
shmerl Member since:
2010-06-08

I didn't see any links to the source and project page yet too. May be the statement came out before the actual opening took place.

Reply Score: 2

MIPSPro ancestry
by Dubhthach on Wed 15th Jun 2011 20:24 UTC
Dubhthach
Member since:
2006-01-12

This compiler set is descended from SGI MIPSPro compiler family via Open64. Awh IRIX happy memories.

Reply Score: 2

RE: MIPSPro ancestry
by _txf_ on Wed 15th Jun 2011 21:08 UTC in reply to "MIPSPro ancestry"
_txf_ Member since:
2008-03-17

This compiler set is descended from SGI MIPSPro compiler family via Open64.


Not via Open64.

This compiler was forked from Pro64 not Open64. However, Open64 contains patches derived from parts of this compiler that were open source before.

Reply Score: 3

Cool and all but...
by Kivada on Thu 16th Jun 2011 06:28 UTC
Kivada
Member since:
2010-07-07

Does this mean anything for us unwashed masses of end users, or is it purely something for the code monkeys to drool over?

Reply Score: 1

RE: Cool and all but...
by lemur2 on Thu 16th Jun 2011 06:43 UTC in reply to "Cool and all but..."
lemur2 Member since:
2007-02-17

Does this mean anything for us unwashed masses of end users, or is it purely something for the code monkeys to drool over?


Using the EKOPath 4 Compiler Suite for compiling most C, C++ and Fortran code for Intel 64 and AMD should result in significant performace improvements over binaries compared to the same source code compiled with GCC.

This means that 64-bit binaries (for programs where you have the source code) will get faster. FOSS software has the source code ... even for drivers and the core OS.

Therefore, any given Linux distribution (for example) now has the opportunity to make significantly faster 64-bit binaries, across the board, than they could previously afford.

Drivers, kernel, graphics layers (including the likes of Cairo, GTK and Qt) ... even media players and codec decoders ... should all get a significant performance boost. Then there are the applications themselves, which should likewise enjoy a performance boost.

It seems to me to be something to really look forward to for end-users (of Intel and AMD 64-bit FOSS systems).

Reply Score: 2

RE: Cool and all but...
by codestr0m on Thu 16th Jun 2011 10:06 UTC in reply to "Cool and all but..."
codestr0m Member since:
2011-06-16

Sorry I'm late to this conversation (actually I'm not sorry based on some of these other posts)

What I'd like to do is share my biased perspective in general. EKOPath has historically catered to a certain audience and as a result a specific type of code. (HPC which is mostly computationally complex stuff) The performance for that does carry over in most cases (not just EKOPath) to other types of code. I'm happy with a bit of hype, but I want people to have realistic expectations. Something like your cli tools are unlikely to see any gains. Something like mesa which was recently benchmarked could see FPS go from 295 to 301 (I don't remember the exact numbers, but you get the idea)

Keep in mind we're not perfect, but.... - If you're code isn't faster we're going to work with you to fix it. So the potential gains long term imho are there for anyone to at least try.

In the future multicore systems are going to be more commonplace. (Even in your mobile phone) The compiler infrastructure needs to be able to handle the different types of optimizations which are needed to ensure best performance. Languages like C++ may get more/less complex. Our goal whether it's for C++/Fortran/ or something new will be the same. ;)

Reply Score: 1

RE[2]: Cool and all but...
by Kivada on Thu 16th Jun 2011 15:53 UTC in reply to "RE: Cool and all but..."
Kivada Member since:
2010-07-07

Nice, going by all this it means that we may even see some nice gains in the CPU limited Gallium3D drivers correct?

Things are looking really good then for my next build if AMD can get Gigabyte to do an A75 Fusion mobo with Coreboot instead of BIOS or UEFI so I can FOSS while I FOSS!

Reply Score: 1