How much of the C++ standard library requires compiler support?

Question

Most of the standard library seems reasonably simple to implement either in terms of other parts of the library, in terms of OS sys-calls, or bare C++ code. A few more bits (e.g. <atomic>) probably require ASM implementations

But at least a few bits seem like they could only be implemented in terms of compiler intrinsics (e.g. <source_location> for sure, std::has_virtual_destructor, a few other parts of <type_traits>, etc).

This last group is of interest specifically because it sort of blurs the line between the standard library and the language standard itself. This is likely one of the most important limits on the portability of library implementations between compilers.

Specifically, my questions is:

Is there a definitive list of the parts that fall into that last category? Is there a specific term the standard uses when talking about those things?

---

Edit:

As a bit of context, this question came up during a thought experiment about what a "bootstrap" compiler & library stack would look like. That is a ball of platform agnostic source code that, with an absolute minimum of manual steps and external dependencies, will get you to a fully standards conforming library and compiler. The focus would not be on performance, but on robustness, simplicity and a minimum kernel of "trust it to actually be correct" external dependencies.

As such, the way things are generally done in practice, or the way they are partitioned up by the standards committee or even what it takes to make a fast compiler (in either sense) are not automatically relevant.

Answer 1

The C++ spec doesn't really consider the library to be separate from the language, so any answer is going to be fairly wishy-washy. However, there is one quirk we can use to kinda-sorta have an answer...

https://eel.is/c++draft/requirements#compliance

"16.4.2.5 Freestanding implementations"

... A freestanding implementation has an implementation-defined set of headers. This set shall include at least the headers shown in Table 27.

		Subclause	Header
	[support.types]	Common definitions	<cstddef>
	[cstdlib.syn]	C standard library	<cstdlib>
	[support.limits]	Implementation properties	<cfloat>, <climits>, <limits>, <version>
	[cstdint.syn]	Integer types	<cstdint>
	[support.dynamic]	Dynamic memory management	<new>
	[support.rtti]	Type identification	<typeinfo>
	[support.srcloc]	Source location	<source_location>
	[support.exception]	Exception handling	<exception>
	[support.initlist]	Initializer lists	<initializer_list>
	[cmp]	Comparisons	<compare>
	[support.coroutine]	Coroutines support	<coroutine>
	[support.runtime]	Other runtime support	<cstdarg>
	[concepts]	Concepts library	<concepts>
	[errno]	Error numbers	<cerrno>
	[syserr]	System error support	<system_error>
	[memory]	Memory	<memory>
	[type.traits]	Type traits	<type_traits>
	[ratio]	Compile-time rational arithmetic	<ratio>
	[utility]	Utility components	<utility>
	[tuple]	Tuples	<tuple>
	[optional]	Optional objects	<optional>
	[variant]	Variants	<variant>
	[expected]	Expected objects	<expected>
	[function.objects]	Function objects	<functional>
	[charconv]	Primitive numeric conversions	<charconv>
	[bit]	Bit manipulation	<bit>
	[string.view]	String view classes	<string_view>
	[string.classes]	String classes	<string>
	[c.strings]	Null-terminated sequence utilities	<cstring>, <cwchar>
	[array]	Class template array	<array>
	[views.contiguous]	Contiguous access	<span>
	[views.multidim]	Multidimensional access	<mdspan>
	[iterators]	Iterators library	<iterator>
	[ranges]	Ranges library	<ranges>
	[algorithms]	Algorithms library	<algorithm>, <numeric>
	[c.math]	Mathematical functions for floating-point types	<cmath>
	[atomics]	Atomics	<atomic>
	[debugging]	Debugging	<debugging>

As near as I can tell, this is a superset of the list of the parts of the standard library that require compiler support and cannot be written to be compiler-independent. Nothing says that officially, but in practice, this list is the closest I've ever found to an objective answer.

In practice, a few of these can be written in portable C++, such as std::string.