Clang 7 separates draft-language experiments from ABI corrections

Experimental support for a future language revision is only one part of a compiler upgrade. Clang 7 also changes how existing C++ classes interact with the platform ABI. The 7.0.0 release notes describe corrections involving packed classes and unnamed bit-fields, while the LLVM release index dates the release to September 19.

The distinction matters because a program need not enable draft-language syntax to encounter a binary compatibility change. A corrected layout or argument classification can affect an existing declaration. Meanwhile, enabling -std=c++2a does not imply that every feature discussed for the next standard is implemented.

C++ gives me useful runtime abstractions, but the language's accumulated rules make release boundaries difficult to summarize. This release needs a specific account of both source support and binary agreement. A general claim about a newer C++ mode would leave out the changes that can matter to already compiled libraries.

The C++2a mode remains a collection of capabilities

Clang's release-branch C++ status document describes experimental support for some proposed C++2a facilities. It warns that support can change or disappear as the draft evolves. The command-line mode selects that experimental interpretation, but individual entries still have their own implementation status.

The table lists default member initializers for bit-fields and __VA_OPT__ among facilities supported since Clang 6. Other items, including designated initializers and the three-way comparison work, have partial status. Concepts and several other draft proposals are not implemented in the listed release-branch account.

That means the mode name is insufficient as a dependency check. A source file can request C++2a and still require a feature the compiler does not provide. It can also use an already supported draft feature without implying that the compiler has completed the remainder of the standard under development.

The table separately lists Technical Specifications. Modules support remains work in progress, while the Coroutines TS uses its own option. Reflection has no implementation listed. These distinctions prevent the word experimental from collapsing several different interfaces and levels of completion into one promised feature set.

Packed inheritance changes in an existing ABI

Clang 7 corrects its handling of GCC's packed class attribute in C++. The release notes say that the attribute now applies to non-static data members rather than base classes. This fixes an ABI disagreement with GCC while creating a disagreement with earlier Clang versions.

The release provides -fclang-abi-compat=6 or a lower value to restore the earlier behavior. That option is about compatibility with an earlier Clang ABI, not about selecting an older C++ language standard. A build can therefore choose its source-language mode and its compatibility behavior for different reasons.

The practical boundary is a class representation shared by separately compiled code. Matching the source declaration does not establish that two compiler versions chose the same layout. The release notes identify exactly the attribute interaction that changed, allowing the affected types to be distinguished from unrelated classes.

The correction also illustrates why compatibility has more than one reference point. Clang 7 becomes compatible with another implementation's interpretation in this case while ceasing to match its own earlier behavior. Neither statement can be reduced to a general assertion that the new compiler is simply more or less compatible.

Unnamed bit-fields affect whether a class is empty

Another correction concerns classes containing only unnamed, nonzero-length bit-fields. Clang implements the proposed resolution of library issue 2358 together with the corresponding Itanium C++ ABI change. Such classes are now considered nonempty for the relevant treatment.

The release notes explicitly describe the resulting ABI break relative to earlier Clang versions and provide the same compatibility option for restoring the previous behavior. The case matters because a member without a usable name can still influence a class's representation and binary classification. Source-level inability to name the field does not imply that the class behaves like an empty argument.

Clang also implements recent corrections to the definition of standard-layout. The notes describe the requirement that base classes and the first data member or bit-field can be laid out at offset zero. This is another property whose interpretation follows detailed class rules rather than the apparent simplicity of the declaration.

I find these narrow descriptions useful when evaluating a compiler release. An ABI concern should identify the type property that changes. That gives the reader a way to reason about a real interface instead of assuming every use of inheritance or every empty-looking type has the same exposure.

Library headers have their own compatibility boundary

The release notes also address programs linking translation units built with different versions of libc++ headers. They direct such users to define _LIBCPP_HIDE_FROM_ABI_PER_TU as one. That is a header-version concern, distinct from the front end's class-layout fixes.

The qualification about mixed translation units is important. The recommendation concerns one final linked image containing code built against different header versions. It should not be generalized into a claim that selecting a C++2a mode automatically chooses this macro or resolves all library ABI questions.

A compiler invocation can make the two principal compiler choices explicit:

clang++ -std=c++17 -fclang-abi-compat=6 -c boundary.cc
clang++ -std=c++2a -c experiment.cc

The first asks for C++17 with an earlier Clang compatibility setting. Draft-language support is requested by the second. These commands describe different compilation policies without demonstrating that either policy supplies every library feature or matches a separately built object.

Clang 7 also distributes the existing diagtool utility. The release notes describe its use in exploring the warning hierarchy and determining which diagnostics are enabled by default or for a particular invocation. That supplies another way to inspect a compilation policy. A warning's availability is separate from whether the chosen invocation enables it, just as a draft feature's presence is separate from the general language-mode name.

Clang 7's release documentation therefore gives several concrete contracts to inspect. Draft features retain individual support status, particular class rules change ABI behavior, and libc++ header mixing has a separate recommendation. Each affects a different part of how source becomes a program assembled from multiple compiled inputs.