LLVM 3.8 Release Notes(llvm.org)
llvm.org
LLVM 3.8 Release Notes
http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html
45 コメント
See the LLVM release notes here: http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html and the Clang release notes here: http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes...
If you want to keep up with the latest LLVM developments, you might want to sign up for my LLVM Weekly newsletter http://llvmweekly.org/
If you want to keep up with the latest LLVM developments, you might want to sign up for my LLVM Weekly newsletter http://llvmweekly.org/
Ok, we changed the URL to the release notes from http://www.llvm.org/releases/download.html#3.8.0.
The original link linked to both llvm and clang release notes.
Thanks, Alex. The newsletter is handy. And belated congratulations BTW.
I love LLVM/Clang but I wish there was a simple tar (or several) I could download and extract on Windows that gave me a full working environment. Finding information on what you need and where you need to put it sucks for someone who wants to just get up and running quickly.
You can download a nice installer from here: http://llvm.org/releases/download.html
What really confused me was that from the llvm front page, if you click Win Installer, you get a version that seems to expect MSVC headers, while if you click LLVM 3.8.0 you get the page you are linking, where the installers appear to expect MinGW headers.
Or perhaps there is some option in both of them to select the other?
Or perhaps there is some option in both of them to select the other?
It seems that the target option might be the one I was looking for.
The installed version defaults to x86_64-pc-windows-msvc, where the msvc at the end suggests it is looking for MSVC headers.
If you specify x86_64-w64-mingw32 as target, it uses the mingw-w64 headers.
The installed version defaults to x86_64-pc-windows-msvc, where the msvc at the end suggests it is looking for MSVC headers.
If you specify x86_64-w64-mingw32 as target, it uses the mingw-w64 headers.
Yes but that installer doesn't actually install a fully working environment, you need the standard library from MinGW or MSVC as well.
That's unlikely to change any time soon, at least from the LLVM side. They're not really in the business of providing OS API headers. At least there's a Windows SDK download now that is smaller than the whole Visual Studio IDE, and the MinGW-w64 project is working on making fully LLVM-based toolchains more usable over time.
It would be nice if they could at least keep the documentation up to date on which MinGW-W64 builds work and which don't etc. I just don't have the time to muck around with things when I can just grab a MinGW build and it "just works" out of the box.
With how friendly Microsoft are getting with Clang I was hoping we might see a LLVM+MSVCHeaders build appear. I am sure it is possible considering the new MS.
I know I am lazy in wanting a one-click solution but my build environment is very important to me. I don't want to have to hack it together using blog posts from 6 months ago that might or might not give me a stable setup. I don't think it is too much to ask for something like TDM's GCC installer.
With how friendly Microsoft are getting with Clang I was hoping we might see a LLVM+MSVCHeaders build appear. I am sure it is possible considering the new MS.
I know I am lazy in wanting a one-click solution but my build environment is very important to me. I don't want to have to hack it together using blog posts from 6 months ago that might or might not give me a stable setup. I don't think it is too much to ask for something like TDM's GCC installer.
You might like Clang with Microsoft CodeGen[1], a work in progress by Microsoft to add a Clang toolset to Visual Studio 2015 that uses the MSVC backend.
[1]: https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-wit...
[1]: https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-wit...
Yeah I have been following the Clang\C2 work. I guess that is what the LLVM project would rather work with Microsoft towards rather than rolling their own. It will certainly make life easier for cross-platform C++ to use Clang/C2 over C1/C2. Having to install Visual Studio to get it is a bit annoying though, I would prefer to fire up a VM with just Clang and the MSVC/Windows headers to command line compile. Visual Studio is a big install inside a VM which is annoying.
I quick question you may know the answer to, does the Windows SDK not come with the Windows C++ headers anymore? I installed the Windows 10 1511 SDK the other day but even a full install didn't give me any of the stdlib which I thought it would do? I understand they removed the compilers but I thought the headers still came with it?
I quick question you may know the answer to, does the Windows SDK not come with the Windows C++ headers anymore? I installed the Windows 10 1511 SDK the other day but even a full install didn't give me any of the stdlib which I thought it would do? I understand they removed the compilers but I thought the headers still came with it?
Oh, bummer, I even thought the Windows SDK still had the command-line compilers. What's it good for then?
Most open-source projects don't even bother supporting MSVC, and I don't blame them one bit. MinGW-w64 gives a significantly less painful route to Windows support, and allows you to pretend MSVC doesn't exist in a lot of cases.
Most open-source projects don't even bother supporting MSVC, and I don't blame them one bit. MinGW-w64 gives a significantly less painful route to Windows support, and allows you to pretend MSVC doesn't exist in a lot of cases.
I am trying to work out what use the Windows SDK is without Visual Studio (which also includes the Windows SDK!).
What benefit does that really have over just using Clang with LLVM codegen though?
http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html
"Slightly less than half of the AVR backend has been merged in at this point. It is still missing a number large parts which cause it to be unusable, but is well on the road to being completely merged and workable."
It would be awesome to be able to use LLVM to cross-compile. Perhaps rust could be made to easily run on a µc at that point!
"Slightly less than half of the AVR backend has been merged in at this point. It is still missing a number large parts which cause it to be unusable, but is well on the road to being completely merged and workable."
It would be awesome to be able to use LLVM to cross-compile. Perhaps rust could be made to easily run on a µc at that point!
> Perhaps rust could be made to easily run on a µc at that point!
That's being worked on: https://github.com/avr-rust/rust
Note that it's mainly the same developer behind the LLVM support as well: https://github.com/avr-llvm/llvm
That's being worked on: https://github.com/avr-rust/rust
Note that it's mainly the same developer behind the LLVM support as well: https://github.com/avr-llvm/llvm
There's a C/C++ frontend/variant of clang that's useful for cross-compiling: ellcc [1].
[1] http://ellcc.org/
[1] http://ellcc.org/
OpenMP FTW!
Also, I'm using libFuzzer in my CPython fuzzer [1], and it's getting more awesome with each release.
[1] https://bitbucket.org/ebadf/fuzzpy
Also, I'm using libFuzzer in my CPython fuzzer [1], and it's getting more awesome with each release.
[1] https://bitbucket.org/ebadf/fuzzpy
Unfortunately the official DEB packages have not been updated in about two months – nightly packages they are not.
http://llvm.org/apt/
http://llvm.org/apt/
> There are numerous improvements to the PowerPC target in this release
That's interesting, who are the current PPC users contributing to LLVM? Is this all from IBM?
That's interesting, who are the current PPC users contributing to LLVM? Is this all from IBM?
Highly quick-and-dirty:
$ git log origin/release_37..origin/release_38 --no-merges -i --grep \
'ppc\|power pc' --pretty='%ae' | grep --only-matching '@.*' | sort | \
uniq -c | sort -rn
16 @anl.gov
11 @gmail.com
7 @linux.vnet.ibm.com
4 @iteratee.net
3 @ca.ibm.com
2 @hanshq.net
2 @de.ibm.com
2 @apple.com
1 @samsung.com
1 @linaro.org
1 @imgtec.com
1 @googlemail.com
1 @codeaurora.org
The @anl.gov is probably this: https://www.alcf.anl.gov/bgclang-compiler
See: https://en.wikipedia.org/wiki/Blue_Gene#Blue_Gene.2FQ
"The Blue Gene/Q Compute chip is an 18 core chip. The 64-bit PowerPC A2 processor cores are 4-way simultaneously multithreaded, and run at 1.6 GHz."
As I know, some of those contributors are just making systemic changes throughout LLVM, which would require touching the PowerPC backend.
I'm not at all surprised at the @[a-z.]+.ibm.com contributors, the @anl.gov is the code maintainer and highly visible contributor. The Argonne National Laboratory run a PowerPC based supercomputer afaik.
I'm not at all surprised at the @[a-z.]+.ibm.com contributors, the @anl.gov is the code maintainer and highly visible contributor. The Argonne National Laboratory run a PowerPC based supercomputer afaik.
It seems a bit low considering IBM is funneling $1 _B_illion into Linux on POWER projects. IBM has long ties to GCC, but LLVM has captured the code generation library market even where gcc is used as the system or application compiler so it's more relevant than ever for them to put some people on it.
IBM makes a lot of announcements with price tags. Their track record says most of that money is spent on developing business applications RUNNING on Linux. Some is spent on FLOSS code contributions, but not the whole $1B.
[deleted]
I'd have to track down where it is in relation to 3.8 release, but Xan López at Igalia has been fixing all the backend blockers to get LLVM on SPARC64/Solaris working properly for us. Can't let the POWER folks get all the RISC legacy love! :)
It seems like rust bundles it's own version of llvm. Are patches from the rust community making it in slowly? Or are there some fundamental differences?
Does Swift do something similar, or does it work with stock llvm?
Does Swift do something similar, or does it work with stock llvm?
It's strange to say it, given that Swift's principal designer is the original creator of LLVM and given that Apple drives the majority of LLVM development, but Swift does indeed ship its own custom version of LLVM: https://github.com/apple/swift-llvm . I'm not sure if, like Rust, Swift also works on stock LLVM.
This is actually quite common. Emscripten ships its own copy of LLVM as well. Rust and Emscripten might actually be combining their efforts into a single LLVM branch this year, in order to provide better WebAssembly support for Rust.
This is actually quite common. Emscripten ships its own copy of LLVM as well. Rust and Emscripten might actually be combining their efforts into a single LLVM branch this year, in order to provide better WebAssembly support for Rust.
I'm curious if you've seen any of the work in-tree that's going on for a native webassembly target in LLVM? It's still early and super rough, but it seems something you may want to peek at.
> It seems like rust bundles it's own version of llvm. Are patches from the rust community making it in slowly? Or are there some fundamental differences?
https://github.com/rust-lang/llvm/commits/rust-llvm-2016-02-...
The delta is minimal, and mostly consists in bugfixes and optimizations. All changes are typically forwarded upstream. Since long time, rustc can be built without using the embedded LLVM, and several distributions (eg. Debian) do that.
https://github.com/rust-lang/llvm/commits/rust-llvm-2016-02-...
The delta is minimal, and mostly consists in bugfixes and optimizations. All changes are typically forwarded upstream. Since long time, rustc can be built without using the embedded LLVM, and several distributions (eg. Debian) do that.
LLVM is a wonderful project, but I dont really know much about this release. How is it significant? Side note, I wonder if this is related to why one of my professors - Dr. Adve - has been so busy lately...
LLVM has done some great things, but I strongly dislike it's license. "Source code under the NCSA license can be incorporated into proprietary products without the reciprocity requirements that copyleft free software licenses raise." -LLVM Wikipedia
For this reason, I will continue to use GCC wherever possible. Not completely on topic, but I just wanted to make the point so that people understand that some of us actually do make decisions not purely from pragmatic standpoints.
For this reason, I will continue to use GCC wherever possible. Not completely on topic, but I just wanted to make the point so that people understand that some of us actually do make decisions not purely from pragmatic standpoints.
Clang's an important project if for one reason that is slowly starting to gain footage in GCC. Everything's callable outside of the compiler. You can have the compiler loop in your IDE, for example, and take advantage of its AST manipulation for better refactoring, its unidentified behavior sanitizer to immediately get a warning when you're heading into the tall grass, etc. GCC is stymied on this part by more conservative elements of their leadership that don't want to expose this behavior that is a growing necessity in code development.
Even if one insists on sticking with gcc on ideological grounds, one should be glad clang exists because it seems to have lit a fire under the maintainers.
The ideological reason to use GCC is to prevent clang/llvm from succeeding, which will drive everyone toward a copyleft product (GCC), which will encourage reciprocity.
Your observation is no consolation for someone who subscribes to that ideology.
(Personally, I do not subscribe to that ideology.)
Your observation is no consolation for someone who subscribes to that ideology.
(Personally, I do not subscribe to that ideology.)
That's great, everybody should use whatever licenses they like, but you're implying that people who don't choose the GPL do it purely from 'pragmatism'. There are plenty of people who choose non-GPL licenses for philosophical and idealistic reasons, and plenty of people who choose the GPL for purely pragmatic business reasons. Your preferences here don't make you any more idealistic or high-minded than anyone else. No one has a moral high ground in the open source world, as much as some people would like to think they do.
"so that people understand that some of us actually do make decisions not purely from pragmatic standpoints."
Well I guess you meant in fact:
"so that people understand that some of us actually do make decisions purely on ideologic standpoints."
Well I guess you meant in fact:
"so that people understand that some of us actually do make decisions purely on ideologic standpoints."
This is a straw man, in the sense that there is a very big difference between "purely on ideologic standpoints" and "not purely pragmatic". A difference that seems obvious if you are interested in intellectualy honest discussion.
OK, you fail to grasp the mechanics here, I think. The NCSA allows you to incorporate NCSA code into your work, which you can then release under GPL if you so choose. What is your beef with that?
Shrink-wrapping [1] moves the prologue/epilogue code that wraps functions in order to setup and tear down their stack frames into the parts of the function that actually need it: consider two control-flow paths, where one doesn't actually need stack space so we can avoid performing those unnecessary instructions.
[1] http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Article...