Previously I wrote:
[Template parameter objects of array type] are permitted to overlap or be
coalesced, just like initializer_lists and string literals. Clang trunk
isn’t smart enough to coalesce potentially non-unique objects [but]
GCC, once it implements define_static_array, will presumably make them the same.
Well, GCC 16 has an experimental implementation of define_static_array
(compile with g++ -std=c++26 -freflection), and it does not coalesce
template parameter objects of array type in the way I expected. Digging deeper
into why not, I learned that there are at least three ways compilers and linkers
(on ELF — that is, non-Windows — platforms) conspire to “merge”
potentially non-unique objects:
- Merging at the compiler level (for
initializer_list backing arrays)
- Sections with
SHF_MERGE (for string literals and backing arrays)
- Sections with
SHF_GROUP, a.k.a. COMDAT sections (for inline variables)
Sadly, no combination of these facilities quite achieves
ideal behavior for define_static_array. Let’s take a look.
The compiler can merge similar data
GCC itself merges similar initializer_list backing arrays. For example
(Godbolt):
void f(std::initializer_list<int>);
int main() {
f({1,2,3}); // C.0.0
f({1,2,3}); // C.1.1
}
turns into the assembly directives
.section .rodata.cst16,"aM",@progbits,16
.align 8
.type C.0.0, @object
.size C.0.0, 12
C.0.0:
.long 1
.long 2
.long 3
.zero 4
.set C.1.1,C.0.0
The symbols C.0.0 and C.1.1 are set to the same memory address, because GCC
itself can see that the two initializer_list objects should have the same backing
array.
This is the most powerful approach, but at the same time the least elegant, because
it requires ad-hoc “smarts” built directly into the compiler. For example, we
could imagine GCC generating code that merges one list into the tail of another:
void f(std::initializer_list<int>);
int main() {
f({1,2,3}); // C.0.0
f({2,3}); // C.2.2
}
C.0.0:
.long 1
.long 2
.long 3
.zero 4
.set C.2.2,C.0.0 + 4
but in fact GCC doesn’t generate that code, because nobody has taught GCC that specific
trick. Nor will GCC 16 merge the backing arrays of {1,2,3} and {1u,2u,3u} using
this technique, again because it hasn’t been taught to.
Merging things at the compiler level also, by definition, works only within a single
translation unit (a single .cpp file). If you want to merge things between different TUs,
you’ll need help from the linker. Which brings us to…
SHF_MERGE sections
I said GCC 16 wouldn’t merge {1,2,3} and {1u,2u,3u} in the compiler. But if you
try this program (Godbolt), you’ll see that the
backing arrays are indeed merged at runtime — the same pointer value is printed twice:
template<class... Ts>
void f(std::initializer_list<Ts>... ils) {
(printf("%p\n", (const void*)ils.begin()) , ...);
}
int main() {
f({1,2,3}, // C.0.0
{1u,2u,3u}); // C.1.1
}
The same pointer value is printed twice, despite that we can see GCC emitting two
different objects into the assembly file:
.section .rodata.cst16,"aM",@progbits,16
.align 8
.type C.0.0, @object
.size C.0.0, 12
C.0.0:
.long 1
.long 2
.long 3
.zero 4
.align 8
.type C.1.1, @object
.size C.1.1, 12
C.1.1:
.long 1
.long 2
.long 3
.zero 4
The trick here is in the .section directive, which creates an ELF section in the
object file with the name .rodata.cst16, the section flag SHF_MERGE (that’s the M
in "aM"), and a sh_entsize of 16 bytes. After concatenating every object file’s
.rodata.cst16 sections as usual, the linker is permitted (but not required) to treat
the contents of this section as an array of 16-byte elements, and to deduplicate any
identical elements it finds. Since the 16-byte region starting at C.1.1 matches the
16-byte region starting at C.0.0, the linker is allowed to eliminate the 16 bytes
at C.1.1 and point the label C.1.1 at C.0.0 (or vice versa).
The SHF_MERGE trick works across TUs, and even across types. For example, GCC 14+
makes the following four initializer lists share a single backing array
at runtime by putting them all into .rodata.cst16 sections with the
SHF_MERGE flag set. This works even if the lists appear in different TUs!
(Godbolt.)
{1,2,3,4}
{1u,2u,3u,4u}
{0x200000001, 0x400000003} // given little-endian int64
{4.2439915824e-314, 8.4879831654e-314} // ditto
The major optimization-related downside of the SHF_MERGE approach — as it is sketched in the
System V ABI document
(2001) and as it is implemented in GNU ld as far as I know — is that you can’t use it to merge data
elements of different sizes or alignments. GCC 16 won’t merge {1,2} with {1,2,3}
because GCC puts the former in section .rodata.cst8 and the latter in .rodata.cst16.
(GCC 14 and 15 put the latter in plain old unmergeable .rodata instead, because
its size — 12 bytes — isn’t precisely 16 bytes. GCC 16 fixed that.) Basically, GCC has to
precommit every data element to a specific “bucket”; the linker will consider merging
it only with other elements in its own bucket.
And SHF_MERGE cannot merge parts of elements; it can merge only full elements.
So while you might think a “sufficiently smart linker” could merge {2,3} across the
conjunction of {1,2} and {3,4}, the SHF_MERGE algorithm by itself will never do that.
Some users might even rely on that guarantee (somehow), so I don’t imagine that
any linker will ever gain the smarts to do that.
SHF_MERGE | SHF_STRINGS
When an ELF section specifies both SHF_MERGE and SHF_STRINGS, then instead of chunking
the section into elements of size sh_entsize bytes, the linker chunks the section into
variable-length elements each of which is a null-terminated C-style string. It then
deduplicates those strings.
As in the previous subsection, it seems that no linker will merge
"ello" into the tail of "Hello"; the SHF_MERGE|SHF_STRINGS algorithm alone
will merge only full elements. (In this case, full null-terminated strings.)
The SHF_MERGE|SHF_STRINGS algorithm finds the “elements” of the section by simplemindedly
scanning for null bytes; no additional metadata is involved. Therefore, such a section must
never contain strings with embedded null bytes. Try the following on your machine:
cat >x.c <<EOF
#include <stdio.h>
int main() {
puts("p");
puts(&"qxp"[2]);
puts("r");
}
EOF
gcc -S x.c -o - | sed 's/qxp/q\\0p/' > x.s
gcc x.s
./a.out
The assembly file x.s should end up containing something like this:
.section .rodata.str1.1,"aMS",@progbits
.LC0:
.string "p"
.LC1:
.string "q\0p" # Danger!
.LC2:
.string "r"
and when executed, will print not p p r but rather p r r, because the SHF_MERGE
algorithm understands "q\0p" as "q" "p" and eliminates the second "p" as a duplicate.
Therefore, a C++ compiler must go out of its way never to store a string literal containing
embedded null bytes into such a section.
const char *p1 = "hello world"; // literal in .rodata.str1.1 (SHF_MERGE)
const char *p2 = "hell\0world"; // literal in .rodata (not SHF_MERGE)
In theory, a compiler could place the backing array for an initializer_list<char>
into a mergeable string section, and potentially merge the backing arrays for
{'x','y','z','\0'} and "xyz". In practice, neither GCC nor Clang does this (yet).
The big disadvantage of SHF_MERGE merging from the C++ compiler’s point of view —
the thing that makes it unsuitable for certain use-cases such as merging the duplicate definitions
of template parameter objects — is that it is completely optional. It’s legal for a
dumb linker to just ignore the SHF_MERGE flag. It would be unwise to rely on SHF_MERGE
to take care of merging objects that the C++ standard requires us to merge, such as the
duplicate definitions of inline variables or template parameter objects.
And, of course, it would be wrong to place an inline variable into an SHF_MERGE section
anyway, because the standard (and common sense) forbids us to merge unrelated inline
variables just because they happen to have the same value!
inline constexpr char a[] = "hello world";
inline constexpr char b[] = "hello world";
Here &a == &b is guaranteed to be false; an implementation that made it true would be
non-conforming. (Even gcc -fmerge-all-constants will make it true, non-conformingly,
only if you remove the inline keyword in both places.)
To handle inline variables, which are deduplicated according to their symbol names
rather than their data contents, we need the next approach, which is…
SHF_GROUP, a.k.a. COMDAT sections
For the past twenty-some years, C and C++ compilers have traditionally compiled
inline functions, inline variables, and implicit instantiations of function and variable
templates into what are called “COMDAT sections.” This feature came late to ELF;
the name “COMDAT” apparently comes
from Windows NT. For more than you ever wanted to know about COMDAT, see
“COMDAT and section group”
(Fangrui Song, July 2021).
ELF’s version of COMDAT was basically designed to do exactly what a C++ compiler needs
in order to implement inline functions. The compiler can take C++ code such as
inline int f() {
static int i = 42;
return ++i;
}
and turn it into a whole group of sections (text, data, rodata, whatever else it needs) —
basically a whole mini object file of its own — something like this:
.section .text._Z1fv,"axG",@progbits,fgroup,comdat
.globl _Z1fv
_Z1fv:
movl _ZZ1fvE1i(%rip), %eax
addl $1, %eax
movl %eax, _ZZ1fvE1i(%rip)
ret
.section .data._ZZ1fvE1i,"awG",@progbits,fgroup,comdat
.globl _ZZ1fvE1i
_ZZ1fvE1i:
.long 42
The assembler emits an ELF section of type SHT_GROUP representing the group of sections
with “group identifier” fgroup. The linker, at link time, will pick one object file’s
fgroup group and throw away the rest.
Now, I simplified that codegen quite a bit. Really, GCC doesn’t make such a human-friendly
section group; it dumps each section into its own individual section group (so in this
example there will be two different group identifiers, not just one); and GCC also marks
both f and i as .weak symbols rather than global. I’m not sure why GCC does these
things; I conjecture “intermediate codegen targeting an object format less powerful than ELF”
and “compatibility with very old ELF linkers lacking SHT_GROUP support” respectively,
but I don’t know. Email and tell me!
COMDAT sections are exactly what you need to implement the definitions of (1) inline functions;
(2) implicit instantiations of function templates; (3) the static local variables of
inline functions and implicitly instantiated function templates; (4) implicit instantiations
of variable templates; (5) inline variables and static inline data members of classes;
and probably a few more things I’m forgetting. All of these are entities with names,
and C++ requires them to be properly deduplicated by name: &myInlineFunc must have the same pointer
value no matter what translation unit you’re in.
Another kind of entity we talked about the other day in
“Things define_static_array can’t do” (2026-04-24):
template parameter objects of class type. Code like this:
template<A t>
const A *f() { return &t; }
will produce a template parameter object “variable” in its own COMDAT section,
like this (Godbolt):
.section .rodata._ZTAXtl1AEE,"aG",@progbits,_ZTAXtl1AEE,comdat
.weak _ZTAXtl1AEE
_ZTAXtl1AEE:
.zero 1
That’s exactly the same strategy the compiler would use for a simple inline variable like
Now, when the linker deduplicates COMDAT sections, it looks at the group identifier (a symbol name)
to decide if two sections are “duplicates” or not. It doesn’t care whether they have the same
bytewise contents. That makes sense, because usually the text sections corresponding to
instantiations of the same inline function in different TUs won’t be byte-for-byte identical
(especially if the two TUs were compiled with different optimization levels). For inline functions,
that’s exactly what we need: deduping by name, not by contents.
You might imagine abusing COMDAT sections to do content-addressed deduplication à la SHF_MERGE.
We just have to put each element in its own individual section group, with a
group identifier based on (the hash of) its contents. For example, instead of
.section .rodata.str1.1,"aMS",@progbits
.LC0:
.string "hello"
.LC1:
.string "world"
.LC2:
.string "hello"
we could emit
.section .rodata.str1.hello,"aG",@progbits,group_hello,comdat
.globl str_hello
str_hello:
.string "hello"
.section .rodata.str1.world,"aG",@progbits,group_world,comdat
.globl str_world
str_world:
.string "world"
But that would be vastly increase the linker’s burden — not just processing all those tiny
sections, but keeping track of all those new global symbols. (We couldn’t use local, internal-linkage
symbols anymore, because the linker wouldn’t be helping us to repoint one symbol’s relocations
at another.) And the compiler would have to dedupe within the TU: we could no longer
refer to "hello" by local symbols like .LC0 and .LC2, but at the same time we couldn’t emit the
global symbol str_hello twice in the same TU.
By the way, making symbol names that incorporate hashes of user-provided data is just asking for trouble.
See “Hash-colliding string literals on MSVC” (2022-12-31).
A hash collision is disastrous; and when someone discovers how to generate hash collisions and starts
writing blog posts like the above, you can’t switch out your hash function for a better one because
that would break ABI.
So it’s very good that we have different, essentially custom-fitted, tools for deduping inline functions
versus string literals.
-
Duplicate inline functions must be merged (we forbid false negatives);
non-duplicates must not be merged (we forbid false positives). Dupe-ness is decided by symbol name;
contents can be different. Duplication need be detected only across TUs; duplication within a single TU
is impossible. Use COMDAT sections.
-
Duplicate strings can be left unmerged (we permit false negatives), although we still forbid false positives.
Dupe-ness is decided by bytewise contents. Duplication should be detected both within and across TUs.
Use SHF_MERGE.
Templates and inline variables can also use COMDAT. A downside is that we’d like to merge the
definitions of e.g. f<char*> and f<void*> when they’re identical (if nothing in the program compares their
addresses), but if dupe-ness is decided by symbol name and those two have different symbols, we’re out
of luck. MSVC has a thing called “Identical Comdat Folding”
that helps with that. (MSVC’s ICF is a non-conforming optimization, because it doesn’t check the parenthetical above.
This can break code:
Godbolt).
Initializer-list backing arrays can use SHF_MERGE too. A downside is that we’d really like to
merge {2,3,4} into the tail of {1,2,3,4}, and the SHF_MERGE algorithm will never do that.
At least the compiler can do that, if someone teaches it to. That compiler optimization “composes”
properly with SHF_MERGE. The compiler could even merge {1,2}, {3,4}, and {2,3} into a single
16-byte element {1,2,3,4} with three embedded labels, which could then merge with {1u,2u,3u,4u}
at link time:
.section .rodata.cst16,"aM",@progbits,16
.C.0.0:
.long 1
.C.1.1:
.long 2
.C.2.2:
.long 3
.long 4
Of course it would be better if the linker could work this out itself; the linker has more
information than the compiler and therefore can do a better job of merging elements. It would also
be nice if we could do something like SHF_MERGE for literals larger than 32 bytes, and/or literals
of lengths that aren’t powers of two. GCC bug #119153
is related.
Contrariwise, C++26 std::define_static_array seemingly cannot use SHF_MERGE, because it cannot tolerate
false negatives: C++26 at present requires us to merge all copies of define_static_array(std::array{1,2,3})
into the same place in memory. That’s too bad, because forcing it to use COMDAT (name-addressed)
instead of SHF_MERGE (data-addressed) means we cannot take advantage of the latitude C++26 gives us to
merge define_static_array(array{1,2,3}) with define_static_array(array{1u,2u,3u}).
Well, we could merge define_static_array(array{1,2,3}) with define_static_array(array{1u,2u,3u})
if we used group identifiers based on a hash of the data! When we tried that on string data
above
we paid a huge performance penalty as well as a correctness penalty. Here we’d pay only
the correctness penalty. It’s still not worth it, IMHO.
Conclusion
Figuring out the best way to “compress” static data using only the tools we’ve got — single-TU ad-hoc compiler
smarts, data-addressed SHF_MERGE, and name-addressed COMDAT sections — is a very hard problem. The implementation
won’t be optimum in every case.
Maybe we could give future linkers even better tools. For example, now that
“potentially non-unique object” is a term of art in C++, maybe we could just dump all PNU objects’ initializers into
a single section (.rodata.pnu?) and in one more special section (.pnu_symtab, storing just a list of indices
into the real .symtab?) specify their starts and sizes — I think that’s all the information the linker needs
in order to overlap them any way it sees fit and repair .symtab accordingly.
Something like that might already exist. If it does, I’d certainly like to hear about it.
And if it doesn’t, I’d certainly like someone to build it!
]]>
]]>