Clang 3.2 Release Notes

• Introduction
• What's New in Clang 3.2?
  • Major New Features
  • New Compiler Flags
  • C Language Changes
  • C++ Language Changes
  • Objective-C Language Changes
  • Internal API Changes
  • Python Binding Changes
• Known Problems
• Additional Information

These are in-progress notes for the upcoming Clang 3.2 release.
You may prefer the Clang 3.1 Release Notes.

Introduction

This document contains the release notes for the Clang C/C++/Objective-C frontend, part of the LLVM Compiler Infrastructure, release 3.2. Here we describe the status of Clang in some detail, including major improvements from the previous release and new feature work. For the general LLVM release notes, see the LLVM documentation. All LLVM releases may be downloaded from the LLVM releases web site.

For more information about Clang or LLVM, including information about the latest release, please check out the main please see the Clang Web Site or the LLVM Web Site.

Note that if you are reading this file from a Subversion checkout or the main Clang web page, this document applies to the next release, not the current one. To see the release notes for a specific release, please see the releases page.

What's New in Clang 3.2?

Some of the major new features and improvements to Clang are listed here. Generic improvements to Clang as a whole or to its underlying infrastructure are described first, followed by language-specific sections with improvements to Clang's support for those languages.

Major New Features

Improvements to Clang's diagnostics

Clang's diagnostics are constantly being improved to catch more issues, explain them more clearly, and provide more accurate source information about them. The improvements since the 3.1 release include:

• -Wuninitialized has been taught to recognise uninitialized uses which always occur when an explicitly-written non-constant condition is either true or false. For example:

  int f(bool b) {
    int n;
    if (b)
      n = 1;
    return n;
  }
  
  sometimes-uninit.cpp:3:7: warning: variable 'n' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
    if (b)
        ^
  sometimes-uninit.cpp:5:10: note: uninitialized use occurs here
    return n;
           ^
  sometimes-uninit.cpp:3:3: note: remove the 'if' if its condition is always true
    if (b)
    ^~~~~~
  sometimes-uninit.cpp:2:8: note: initialize the variable 'n' to silence this warning
    int n;
         ^
          = 0
  

  This functionality can be enabled or disabled separately from -Wuninitialized with the -Wsometimes-uninitialized warning flag.
• Template type diffing improves the display of diagnostics with templated types in them.

  int f(vector<map<int, double>>);
  int x = f(vector<map<int, float>>());
  

  The error message is the same, but the note is different based on the options selected.

  template-diff.cpp:5:9: error: no matching function for call to 'f'
  int x = f(vector<map<int, float>>());
          ^
  

  Templated type diffing with type elision (default):

  template-diff.cpp:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], float>>' to 'vector<map<[...], double>>' for 1st argument;
  int f(vector<map<int, double>>);
      ^
  

  Templated type diffing without type elision (-fno-elide-type):

  template-diff.cpp:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, float>>' to 'vector<map<int, double>>' for 1st argument;
  int f(vector<map<int, double>>);
      ^
  

  Templated tree printing with type elision (-fdiagnostics-show-template-tree):

  template-diff.cpp:4:5: note: candidate function not viable: no known conversion for 1st argument;
    vector<
      map<
        [...],
        [float != double]>>
  int f(vector<map<int, double>>);
      ^
  

  Templated tree printing without type elision (-fdiagnostics-show-template-tree -fno-elide-type):

  template-diff.cpp:4:5: note: candidate function not viable: no known conversion for 1st argument;
    vector<
      map<
        int,
        [float != double]>>
  int f(vector<map<int, double>>);
      ^
  

• Clang's -fcatch-undefined-behavior option has grown the ability to check for several new types of undefined behavior.

Support for tls_model attribute

Clang now supports the tls_model attribute, allowing code that uses thread-local storage to explicitly select which model to use. The available models are "global-dynamic", "local-dynamic", "initial-exec" and "local-exec". See ELF Handling For Thread-Local Storage for more information.

The compiler is free to choose a different model if the specified model is not supported by the target, or if the compiler determines that a more specific model can be used.

Type safety attributes

Clang now supports type safety attributes that allow checking during compile time that 'void *' function arguments and arguments for variadic functions are of a particular type which is determined by some other argument to the same function call.

Usecases include:

• MPI library implementations, where these attributes enable checking that buffer type matches the passed MPI_Datatype;
• HDF5 library -- similar usecase as for MPI;
• checking types of variadic functions' arguments for functions like fcntl() and ioctl().

See entries for argument_with_type_tag, pointer_with_type_tag and type_tag_for_datatype attributes in Clang language extensions documentation.

New Compiler Flags

• -gline-tables-only controls the size of debug information. This flag tells Clang to emit debug info which is just enough to obtain stack traces with function names, file names and line numbers (by such tools as gdb or addr2line). Debug info for variables or function parameters is not produced, which reduces the size of the resulting binary.
• -ftls-model controls which TLS model to use for thread-local variables. This can be overridden per variable using the tls_model attribute mentioned above. For more details, see the User's Manual.

C Language Changes in Clang

C11 Feature Support

...

C++ Language Changes in Clang

C++11 Feature Support

...

Objective-C Language Changes in Clang

...

Internal API Changes

These are major API changes that have happened since the 3.1 release of Clang. If upgrading an external codebase that uses Clang as a library, this section should help get you past the largest hurdles of upgrading.

API change 1

...

Python Binding Changes

The following methods have been added:

• ...

Significant Known Problems

Additional Information

A wide variety of additional information is available on the Clang web page. The web page contains versions of the API documentation which are up-to-date with the Subversion version of the source code. You can access versions of these documents specific to this release by going into the "clang/doc/" directory in the Clang tree.

If you have any questions or comments about Clang, please feel free to contact us via the mailing list.