chandlerc1024

8 ms·

31.
by chandlerc1024 8y ago
The intent is definitely to handle this as well. (Not really going to try and dig into legal reasoning here.)
32.
by chandlerc1024 8y ago
Doh!
33.
by chandlerc1024 8y ago
FWIW, we definitely looked at a dual-license style approach. One thing that I keep pointing out is that the Apache provides a way for the license to be self-executing. This is really cool (although also one source of objections) and IMO sup
34.
by chandlerc1024 8y ago
The interesting thing is that the vast majority (and for the first year+ all) of the contributors to LLVM who donated massive amounts of time and resources to make the relicensing happen were not from any company that was blocked from con
35.
by chandlerc1024 8y ago
FreeBSD is OK with the license, so AFAIK, it is just OpenBSD. We did listen, but we have specific goals that after a great deal of discussion are best addressed with the approach of the Apache 2 license. The objection was to those goals i
36.
by chandlerc1024 8y ago
FWIW, Apache2 has other really useful aspects such as being self executing. We looked at options very similar to BSD w/ a patents clause and they ended up being less good on several fronts. Of course, YMMV, this was specifically in the
37.
by chandlerc1024 8y ago
I wouldn't call LLVM "mostly Apple owned" at this point. It has a huge range of contributions from Apple, Google, and many others. Even Microsoft! =]
38.
by chandlerc1024 8y ago
True. FWIW, this is really the only strong objection we've heard to the overall direction of this change.
39.
by chandlerc1024 8y ago
Heather is "just" a (fantastic) lawyer. She isn't providing the "here is what would be good for the project" direction, the community and the foundation are doing that. She is helping ensure that we understand the l
40.
by chandlerc1024 8y ago
If you can reuse the legal mechanics of the new LLVM license, maybe that helps? We spent a LOT of lawyer time trying to get this right.
41.
by chandlerc1024 8y ago
We are successfully moving towards the next bug milestone which will put the new license in place going forward. This is likely among the most potentially disruptive steps as we need to ensure subsequent contributions are under the new lice
42.
by chandlerc1024 8y ago
Other than the AVX side channel, the interesting thing is that it demonstrates that the remote aspect definitely works. Before, it was theorized but might have proven to never give sufficient signal. While many were confident, now we know.
43.
CppCon 2018 Plenary: Spectre: Secrets, Side-Channels, Sandboxes, and Security(cppcon.org)
3 points by chandlerc1024 8y ago|0 comments
44.
by chandlerc1024 9y ago
My memory is that it supports DWARF debug info. So you get full debug info in DWARF and can use the mingw port of GDB on Windows. Still, this is very different from the first-class support for compatible debug info that Clang provides.
45.
by chandlerc1024 9y ago
Yes. (To the extent possible. There are some edge cases left, but they're very rare. Essentially all the real-world code we've seen works now.)
46.
by chandlerc1024 10y ago
And it's fixed! =] https://github.com/Microsoft/DirectXShaderCompiler/pull/33 https://github.com/Microsoft/DirectXShaderCompiler/issues/30
47.
by chandlerc1024 10y ago
You are tarring all compiler authors with a very broad brush here. Myself and other compiler authors I work with are much more specific in their requests. We do actually define some behavior that the standard doesn't require, and we do
48.
by chandlerc1024 10y ago
That comment was actually a considered comment: when we look at what warnings we should produce, we consider cases where everyone has written code a particular way and the fact that it isn't defined is actually a language bug. We (the
49.
by chandlerc1024 10y ago
The compiler is not producing C code that calls memcpy. It is leveraging a specific implementation of a memcpy symbol in a particular system library. The contract between Clang and that system library can include guarantees not provided by
50.
by chandlerc1024 10y ago
I want to assure you that the compiler does not exclusively use the ISO language standard to define the behavior of internal components of the implementation.
51.
by chandlerc1024 10y ago
Essentially. But I think Clang can actually do better here. The open source project is essentially providing integration with glibc and other libcs and we don't do a reasonable job of being conservative there where we don't know
52.
by chandlerc1024 10y ago
On at least one platform, all future libc revisions will abide by this requirement. And neither Clang nor LLVM are generating platform agnostic code. The code only has meaning for the specific platform being targeted.
53.
by chandlerc1024 10y ago
No, Clang cannot guarantee its own memcpy implementation will be used. But it can be aware of which implementation will be used and make specific assumptions about that implementation in some cases . The specific cases are when it has a ge
54.
by chandlerc1024 10y ago
Understand that some of the folks who don't think this is a bug own one of the libc implementations being used . So for their platform, it really is 100% correct and valid. The folks working on other platforms seem universally unhappy
55.
by chandlerc1024 10y ago
Hi, LLVM and Clang developer here. I don't see anyone being blasé about this. The issue comes down to something really simple: - The compiler can emit substantially simpler code if it has a guarantee from the platform's implementa
56.
by chandlerc1024 11y ago
No, it can't generate a PDB file itself, at least not today. Maybe in the future the MSVC linker will be able to generate one even though you compiled with Clang/LLVM (it does that already today but the PDB file is almost empty).
57.
by chandlerc1024 14y ago
I do work at a company ( not Apple), developing compilers -- specifically Clang. I know most of the folks working on Clang at Apple, and I know Douglas Gregor quite well. I'm on Doug's study group working on modules. So, I think I have som