GCC 8 expands C++ support while correcting binary boundaries

A compiler can accept more C++ source while also changing how existing source crosses a binary boundary. GCC 8.1, released on May 2, has both kinds of change. It expands the C++17 library and adds experimental C++2a support. Its calling-convention corrections also affect particular classes passed to or returned from functions.

These are separate compatibility questions. Source-language acceptance describes what the front end understands. Library availability describes the facilities supplied by the accompanying headers and runtime. The ABI describes how separately compiled code agrees about calls and representations. Naming a newer language mode does not answer all of them.

I value C++ abstractions when their runtime cost remains close to the underlying operations. That makes the binary details important even for classes whose source looks trivial. A type can contain no data members and still participate in a function signature whose calling convention must agree across every compiled participant.

An empty argument still has an ABI rule

The GCC 8 changes document describes a correction for passing empty classes on x86-64. Such an argument now takes no space, as required by the platform ABI. The class's source declaration need not change for a rebuilt function call to use the corrected convention.

The consequence depends on the boundary. If every caller and callee is compiled with the same convention, they can agree. If separately built objects use different conventions for an affected signature, agreement cannot be inferred from matching source declarations alone. The ABI is the additional contract that connects those declarations at runtime.

The release notes identify -Wabi=11 as a way to ask about changes relative to GCC 7's ABI. They also describe -fabi-version=11 for selecting that earlier convention. These controls concern the compiler's ABI behavior. They do not select C++11 as the source language merely because the option contains the number eleven.

The 8.1 C++ dialect manual explains the general distinction. -fabi-version chooses an ABI version, while its default value zero means the version that most closely follows the ABI specification. That default can change across compiler releases as the compiler corrects ABI defects.

Deleted constructors expose another calling-convention case

GCC 8 also corrects passing or returning classes whose copy and move constructors are both deleted. The release notes say these use the same calling convention as classes with a nontrivial copy or move constructor. They identify this as relevant to C++17 mode because the corresponding passing or returning case was impossible in earlier modes.

The relationship to C++17's temporary-object rules is visible in the versioned manual. Its discussion of -fno-elide-constructors says that C++17 requires omission of the relevant temporaries, so the option cannot force their creation in those cases. A compiler flag that previously exposed copies cannot override a language requirement that removes them.

That matters when reasoning from constructor availability to call behavior. A function result can be valid under C++17 without a usable copy or move constructor, but the compiler still needs an ABI representation for passing the result. The absence of those operations does not remove the need for agreement between caller and callee.

It also explains why ABI changes belong in a release discussion alongside new facilities. Adopting a source-language mode can expose cases that were not expressible under earlier rules. Once those cases exist, the implementation must specify and correctly implement their machine-level boundary as well.

Library support is more specific than a language flag

The release's library additions include class template argument deduction guides, std::filesystem and integer forms of std::to_chars and std::from_chars. The qualification on character conversion is significant. GCC 8's announced support covers integers, not floating-point overloads.

That gives a concrete example of why a general C++17 label is insufficient when checking a required facility. Two overload families can share a standardized name while having different implementation status. A program that needs floating-point conversion cannot infer availability from the presence of integer conversion support in the same header.

The changes document also says that char_traits<char> and char_traits<wchar_t> are usable in constant expressions. That is a library capability involving compile-time evaluation. It should be distinguished from changing the set of expressions the core language permits in a constexpr function. A usable facility depends on both layers meeting the requirements of the program.

Experimental C++2a library additions include std::to_address and std::endian. Their presence does not make every C++2a library proposal available. The release announcement describes support for some draft facilities, and the 8.1 language-mode documentation calls the mode highly experimental with possible incompatible changes.

Experimental syntax is explicitly selected

The new draft-language support uses -std=c++2a or -std=gnu++2a. GCC 8's ordinary C++ default remains GNU C++14 according to its versioned dialect documentation. Installing the compiler therefore does not automatically put every C++ source file into its experimental mode.

A build can state the distinction directly:

g++ -std=c++17 -Wabi=11 -c interface.cc
g++ -std=c++2a -c experiment.cc

The first command selects C++17 and asks about ABI changes relative to the specified earlier version. The second opts into the draft language. Neither command establishes that arbitrary objects compiled elsewhere use matching options or that every proposed library facility is implemented.

The announced draft features include designated initializers and default member initializers for bit-fields. The release also supports __VA_OPT__, with an explicitly documented exception for its stringized form. Those details are more useful than treating experimental support as a single yes-or-no capability. Code can require one supported feature while avoiding another still-unimplemented form.

Diagnostics make some existing abstractions easier to inspect

GCC 8 adds -Wclass-memaccess under -Wall. It diagnoses potentially unsafe raw-memory operations on nontrivial class types, including operations that bypass user-defined constructors or assignment, damage internal representation, or circumvent access controls. The warning concerns the mismatch between the class's semantic operations and the raw operation applied to its storage.

That diagnostic fits the release's broader boundary changes. A source-level class can have obligations that copying its bytes does not honor. The compiler now has another way to report that mismatch. Recognizing the warning does not require treating all byte operations on all objects as equivalent or assuming every class has the same copy semantics.

Template diagnostics also improve. The changes document describes highlighting differing parts of template types and eliding matching parameters. -fno-elide-type restores the full types, while -fdiagnostics-show-template-tree presents mismatches hierarchically. These options affect the explanation of a type mismatch, not whether two different specializations become interchangeable.

I regard this diagnostic work as part of the cost of supporting C++ abstractions. When a type expression is large, showing the part that differs helps the programmer locate the actual failed requirement. The implementation still needs the full type, but the person reading the error can begin with the difference that matters.

The porting guide also explains that alignof now returns the minimum alignment required by the target ABI, matching C's _Alignof, instead of the preferred alignment exposed by GNU __alignof__. On the cited 32-bit x86 case, that changes the result for double. Code seeking preferred alignment needs the latter operation explicitly.

This is another case where an established expression can change without a new application feature. GCC 8.1 expands what programs can express and improves diagnostics, while its ABI and alignment corrections refine what existing expressions mean at platform boundaries. Assessing a build requires identifying the particular facility or convention involved, including the language mode and library overloads it actually uses.

The porting guide gives a concrete relationship behind the alignment correction. A structure containing a double member follows the ABI's required member alignment. Returning a larger preferred alignment for double could make a comparison between the structure's alignment and the member type's alignment fail. Returning the required alignment lets the language operation describe the same minimum constraint in both places. A preferred alignment remains a useful implementation choice, but it answers a different question.

The same guide explains the newly default -Wreturn-type warning in C++. GCC treats reaching the end of a non-void function as unreachable for optimization purposes. A warning on that path is consequently evidence about a semantic assumption used by generated code. Treating it merely as missing documentation would overlook why an apparently successful compilation can still produce incorrect execution.