nickdesaulniers added a comment. Just some more thoughts after being able to sleep on it.
The merge-able sections is generally handy for sections which I'm not specific about (in the added test case, the "implicit" sections). For example, if I have global const data that I don't take the address of and has internal linkage, then rather it be in `.rodata`, it's handy for LLVM to suffix it into separate `.rodata.cst4`, `.rodata.cst8`, etc. sections that ARE merge-able and have uniform entity sizes. But, if I explicitly state that I want something (code or data) in a specific section, it would be surprising to me if the compiler changed the section I explicitly specified to put that in anything other than what I specified, and that included adding suffixes (like `.cst4`, `.cst8`, etc). Especially if I was manually performing relocations manually via libelf, or like the Linux kernel does. If I put data in `.foo`, and try to look it up at runtime explicitly, I might be surprised if it was moved to `.foo.cst8`, for example. If I'm explicitly putting code or data in explicit sections and actually care about those sections being merge-able, than I'd better also be proficient enough in linker scripts to explicitly merge those sections together myself. Otherwise, I don't see GCC putting explicitly-sectioned data in merge-able sections, even with `-fmerge-all-constants` (which is already a dangerous flag to use) (GCC will put implicitly-sectioned data in merge-able if you specify `-fmerge-all-constants`, but that's not relevant for this patch which is about //explicitly-sectioned// code/data). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68101/new/ https://reviews.llvm.org/D68101 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
