https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125196
Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arthur.j.odwyer at gmail dot
com
--- Comment #1 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
FYI: I mention this issue (more or less) in my today's blog post,
https://quuxplusone.github.io/blog/2026/05/05/potentially-nonunique-strategies/
The trick with this example is that the initializer list is just too big to fit
in .rodata.cst16, .rodata.cst32, etc. If it *did* fit in one of those
"buckets," then gcc-the-compiler wouldn't have to worry about it at all — as it
currently doesn't — because SHF_MERGE would take care of deduplication. But
because gcc-the-compiler puts this 64-byte array into plain old uncategorized
.rodata, the linker can't help us out here.
In this specific case, the length of the data happens to be a power of 2, so we
could fix it by just inventing an .rodata.cst64. But IMHO that would be
unsatisfactory, because suppose the data were of length, like, 32777. We
wouldn't want to place it in ".rodata.cst65536"! The solution should be
general-purpose — and might involve inventing a new ld feature.
