FYI, gcc uses "aG".

A c++ testcase:

class foo {
public:
void test() {
static const char v[1] = { 1 };
}
};
void foobar() {
foo rep;
rep.test();
}

gcc produces

.weak _ZZN3foo4testEvE1v
.section .rodata._ZZN3foo4testEvE1v,"aG",@progbits,_ZZN3foo4testEvE1v,comdat
.type _ZZN3foo4testEvE1v, @​object
.size _ZZN3foo4testEvE1v, 1
_ZZN3foo4testEvE1v:
.byte 1

we produce

.type _ZZN3foo4testEvE1v,@object
.section .gnu.linkonce.r._ZZN3foo4testEvE1v,"aM",@progbits
.weak _ZZN3foo4testEvE1v
_ZZN3foo4testEvE1v: # _ZZN3foo4testEvE1v
.size _ZZN3foo4testEvE1v, 1
.ascii "\001"

I now think that the correct fix is to print a ", 1" in the section line after
@​progbits (or to use comdat as gcc does).

A hack that fixes the bug
The attached patch is a hack, but it fixes the bug and "make check" has no regressions.

What is the proper way to do this? Should I remove MergeableConst{4,8,16}?

now it really fixes it :-)

Just bumping up severity a bit, since this can also cause linker errors, not just warnings.

I'm sorry, I missed this bug. Taking a look now, sorry!

I opted to go for the simple fix:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090727/083081.html

This returns us back to previous behavior. I'd like to get further along with the section selection refactoring stuff before making it more complex.