Non-determinism in bitcode writer for __asm__ ".symver"

[pirama-arumuga-nainar]

This was observed when building AOSP's external/libfuse/lib/fuse.c with ThinLTO. Here's a reproducer:

$ cat asm.c
__asm__("\t.symver " "fuse_loop_mt_32" "," "fuse_loop_mt@@FUSE_3.2");
int fuse_loop_mt_32()
{
 return 0;
}

__asm__("\t.symver " "fuse_loop_mt_31" "," "fuse_loop_mt@FUSE_3.0");
int fuse_loop_mt_31()
{
 return 0;
}

__asm__("\t.symver " "fuse_new_31" "," "fuse_new@@FUSE_3.1");
int fuse_new_31()
{
 return 0;
}

__asm__("\t.symver " "fuse_new_30" "," "fuse_new@FUSE_3.0");
int fuse_new_30()
{
 return 0;
}
$ for trial in {1..10}; do clang -c -flto=thin -o asm.o asm.c; mv ./asm.o ./asm_${trial}.o; done; sha256sum asm_*.o
7ee03d86cbd050146295325f1df1be2ee21ff5305d3d8f44b8c3084f7e032bd0  asm_10.o
3dd67c2162022d353a20395e4d0e58c652aacb35b31a4c6698ab022ea9595e1d  asm_1.o
c74891863f6bc410f715bc2b9af7731cf70f5771eb904a8c6548dde5a3c88a19  asm_2.o
7ee03d86cbd050146295325f1df1be2ee21ff5305d3d8f44b8c3084f7e032bd0  asm_3.o
1923c4f6570916bab428bc6d7a132fc14d211259ad284a492b7710d88abb1ff3  asm_4.o
3dd67c2162022d353a20395e4d0e58c652aacb35b31a4c6698ab022ea9595e1d  asm_5.o
3dd67c2162022d353a20395e4d0e58c652aacb35b31a4c6698ab022ea9595e1d  asm_6.o
1923c4f6570916bab428bc6d7a132fc14d211259ad284a492b7710d88abb1ff3  asm_7.o
c74891863f6bc410f715bc2b9af7731cf70f5771eb904a8c6548dde5a3c88a19  asm_8.o
c74891863f6bc410f715bc2b9af7731cf70f5771eb904a8c6548dde5a3c88a19  asm_9.o

Converting the .o to LLVM IR using llvm-dis produces identical outputs. So does removing -flto=thin.

[pinskia]

The way GCC is solving symver with LTO is adding an attribute (though there seems to be some issues with it still). See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 .