LLVM Project Blog
LLVM Project News and Details from the Trenches
Monday, November 18, 2013
Tuesday, November 5, 2013
There has been a lot of work lately towards bringing an LLVM toolchain to the Windows platform (see A path forward for an LLVM toolchain on Windows). One result of that work is a new driver mode for Clang: clang-cl. This mode makes Clang understand the same kind of command-line arguments as Visual Studio's compiler, cl.exe. For example, a typical command to compile a file into an executable with Clang might be "clang hello.cc -o hello", whereas with cl.exe, one would use "cl.exe hello.cc /Fehello". Now one can use the latter syntax with Clang by substituting "cl.exe" with "clang-cl". This makes it easy to use Clang for existing projects in Visual Studio.
For the most part, clang-cl accepts exactly the same arguments as cl.exe. However, it also accepts some Clang-specific options. One such option that was added recently is the /fallback flag. The purpose of this flag is to make it easy to use clang-cl even in projects where Clang cannot yet compile all of the code. This post gives an example of how /fallback can be used.
Friday, October 11, 2013
The new unwinder has been added to the libcxxabi.llvm.org project. The unwinder has two levels of API. The high level APIs are the _Unwind_* functions which the cxa_* exception functions in libcxxabi require. The low level APIs are the unw_* functions which are an interface defined by the the old HP libunwind project (which shares no code with this libunwind).
Most architectures now use "zero cost" exceptions for C++. The zero cost means there are no extra instructions executed if no exceptions are thrown. But if an exception is thrown, the runtime must consult side tables and figure out how to restore registers and "unwind" from the current stack frame to the catch clause. That ability to modify the stack frames and cause the thread to resume in a catch clause with all registers restored properly is the main purpose of libunwind.
The new unwinder sources are known to build on Darwin, but will need some #defines configured to build on other platforms (patches welcome!). The low level libunwind API was designed to work either in-process (aka local) or to operate on another process (aka remote), but only the local path has been completed, as that is all that C++ exceptions require.
Tuesday, October 8, 2013
Monday, September 23, 2013
In April of 2013, the C++ standards committee approved a draft version of the next revision of the C++ language, called "C++1Y". (C++11 was called "C++0x" while in development). We hope that this draft standard will be approved next year, and become C++14.
The draft standard includes changes to both the language and the standard library. These changes are designed to correct some mistakes that have been discovered in the C++11 standard and to add new features.
Both clang and libc++ are being enhanced to support this new standard, and they each have a web page to show their current progress: clang C++1Y Status and libc++ C++1Y status.
The C++ standards committee is meeting this week (September 23-28) to consider comments and defect reports in the C++1Y draft standard, and there will certainly be changes made.
We could have waited until the final version of the C++1Y standard was approved; that would certainly have been less work. The draft standard will to be revised in September (and probably in February), so the libc++ implementation will have to change to track the standard.
However, by implementing the draft standard has several advantages.
- We gain experience in working with the new standard.
- We found several places where the changes to the draft standard "exposed" other places were improvements can be made. For example, while implementing the new
optionalfeature made it clear that interface of the the comparison functions
less(and others) could be enhanced. The result of that was the new paper n3749.
- By implementating the standard, we can identify problems/inconsistencies in the draft standard. For example, when we implemented the new library feature
dynarray, we discovered that the interfaces for the allocator-based constructors for the container were wrong; in particular there were cases where it was not possible for the compiler to determine the correct constructor to call. This was raised as LWG Issue 2255, and will have to be resolved before the standard becomes final.
Thursday, September 5, 2013
Over the past several months, contributors from Google and elsewhere in the community have begun actively working on bringing an LLVM toolchain to Windows in a way that would support and enhance a fully native development experience. This toolchain works with Visual Studio and the Windows development process that Windows developers are already using, making LLVM tools and technologies available to them. We want to cross the streams (in the Ghostbuster proton-pack sense) of the Visual Studio IDE and the LLVM-based C++ tools to enable developers to build C++ software better.
To that end, we’ve been driving many of the efforts around compatibility with Visual Studio and native Windows C++ code in Clang and LLD (the LLVM linker). Today, as announced at my GoingNative 2013 talk, we are able to build a trivial C++ application that in turn links against native C++ libraries and uses them in real, interesting ways. This is a huge milestone for the project, and something we’re really excited to be talking more about. Lots of folks in the LLVM project came together to get the open source project here. Thanks to every single one of you.
Going forward, we would really like to see an increased level of involvement from Windows developers. We’re launching an alpha-build website as part of llvm.org where you can get fresh builds of Clang, various Clang-based-tools, LLD, and the rest of the LLVM toolchain for Windows on a regular basis. These installable packages should make it dramatically easier to test and experiment with this new set of tools in your development environment. Please feel free to try it out, file bugs, and even submit patches to help move the toolchain forward on this new platform. Keep in mind, we are following the tried-and-true open source release mantra of releasing early and frequently. These are alpha-quality releases intended at developers interested in helping us track down and understand bugs.
There is still a lot of exciting work left to make LLVM and the C++ toolchain built on top of LLVM fully support the Windows platform. Come join the fun, because this is one place where patches are truly welcome.-Chandler Carruth
Wednesday, September 4, 2013
Clang has two types of diagnostics, errors and warnings. Errors arise when the code does not conform to the language. Such things as missing semi-colons and mismatched braces prevent compilation and will cause Clang to emit an error message.
On the other hand, warnings are emitted on questionable constructs on language conforming code. Over time, certain patterns have been determined to have a strong likelihood of being a programming mistake. Some examples of these include: order of operations confusion, mistaking similarly named language features, and easily made typos that still result in valid code.
Although warnings may have false positives, the utility of finding bugs early usually outweigh their downsides. Keep reading for a demonstration of Clang's warnings, as well as a comparison to GCC's warnings.