Meanwhile, Mesa developers merged ACO compiler for AMDGPU, as the future replacement for llvm.
LLVM 9.0
41–50 of 111 posts
Re: LLVM 9.0
#42Earlier quoted context omitted.
Doesn't the "LLVM Exceptions" part of the license take care of the patent issue you mention? "[...] if a court of competent jurisdiction determines that the patent provision (Section 3), [...] conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License [...]" Source: https://github.com/llvm/llvm-project/blob/master/llvm/…
It wouldn't cover anything from OpenBSD, if as excerpted by you, it only covers exceptions related to GPLv2 as I don't believe OpenBSD considers GPLv2 to be acceptable either.
> I don't believe OpenBSD considers GPLv2 to be acceptable either.
The GPLv3 is not acceptable in base at all, GPLv2 is unacceptable for new code, but we still have a few examples in base, very few.
Re: LLVM 9.0
#43Earlier quoted context omitted.
Doesn't the "LLVM Exceptions" part of the license take care of the patent issue you mention? "[...] if a court of competent jurisdiction determines that the patent provision (Section 3), [...] conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License [...]" Source: https://github.com/llvm/llvm-project/blob/master/llvm/…
It wouldn't cover anything from OpenBSD, if as excerpted by you, it only covers exceptions related to GPLv2 as I don't believe OpenBSD considers GPLv2 to be acceptable either.
My reading of the LLVM Exceptions statement is that if a judge understands the the Apache 2.0 patent provision section (and others) to not be the same as GPLv2, then the section is waived. The preamble of the GPLv2 summarizes its stance on patents in lay terms that seem to be compatible with what OpenBSD wants:
"We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all."
Source: https://opensource.org/licenses/gpl-2.0.php
(I'm not a lawyer)
Re: LLVM 9.0
#44Earlier quoted context omitted.
I don't see this change breaking the examples you have given. You can always modify non-const objects. What you can't do is modify const objects through a pointer to non-const. e.g. ((char*)"fooo")[0] = 1 is broken code but int x = 0; int const* y = &x; *((int*)y) = 1; is not.
That's not what I got from the quoted paragraph. I'll have to chase the links to be sure.
In LLVM terms, it's referring to these kinds of stores:
@vval = constant double 1.0, align 8
define void @foo(double *val) {
store double %val, double @cval, align 8
|
Re: LLVM 9.0
#45Earlier quoted context omitted.
Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how We…
The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside,…
Google has already achieved that with Project Treble by the way.
Re: LLVM 9.0
#46Earlier quoted context omitted.
It wouldn't cover anything from OpenBSD, if as excerpted by you, it only covers exceptions related to GPLv2 as I don't believe OpenBSD considers GPLv2 to be acceptable either.
My reading of the LLVM Exceptions statement is that if a judge understands the the Apache 2.0 patent provision section (and others) to not be the same as GPLv2, then the section is waived. The preamble of the GPLv2 summarizes its stance on patents in lay terms that seem to be compatible with what OpenBSD wants: "We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses…
The exemption you quoted very specifically says it applies "if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision […] conflicts with the conditions of the GPLv2" (emphasis mine). I don't know how you could read that as applying to situations where nothing is licensed under the GPLv2.
In other words, it sounds like this would address OpenBSD's concerns if OpenBSD were GPL-licensed — but it isn't.
Re: LLVM 9.0
#47Earlier quoted context omitted.
> Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? It was already possible to compile the kernel with clang/llvm. But a few releases ago, the Linux kernel dropped support for being built with older compilers which did not have support for the "asm goto" gcc extension. The Linux kernel has always targeted gcc exclusively, and makes heavy use of gcc extensions since its very…
Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/c…
Who in the world would do that rather than just supporting both compilers?
Re: LLVM 9.0
#48> LLVM will now remove stores to constant memory (since this is a contradiction) under the assumption the code in question must be dead. This has proven to be problematic for some C/C++ code bases which expect to be able to cast away ‘const’. This is (and has always been) undefined behavior, but up until now had not been actively utilized for optimization purposes in this exact way. For more information, please see:…
I guess the question is: will it silently optimize them away or will it be a compile error to use such expressions?
It can't be a compile error. It's not an error for a program to contain such code, it's only an error if that code executes.
Re: LLVM 9.0
#49Earlier quoted context omitted.
Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/c…
Who in the world would do that rather than just supporting both compilers?
You don't seems to understand that extensions/attributes can have a usefulness that far outweight cross compiler compatibility?
Type of reasons: Performance critical; Security; Expressivity;
Each of them can be a necessary reason. E.g "polymorphism" in C through transparent unions
Re: LLVM 9.0
#50Earlier quoted context omitted.
memcmp has to find the first offset where the buffers differ, and check which of them is larger. bcmp only has to figure out whether the buffers differ. It doesn’t have to figure out where they differ. For example, for s=1024 , bcmp can do (at most) 128 64-bit compares (using vector registers, it could even use larger steps) memcmp could do the same, with an additional “figure out where in the last 8-byte parts compa…
This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.
The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.