[llvm-profdata] nodeduplicate has been violated!

[wolfy1961]

Bugzilla Link	51394
Version	trunk
OS	Windows NT
CC	@gregbedwell,@pogo59,@petrhosek

Extended Description

After c24b7a1 we get the error in the subject line with -flto -fprofile-instr-generate:

1.cpp:
attribute((weak)) void f(){};

2.cpp:
int main(){}

clang -flto -fprofile-instr-generate -c 1.cpp -o 1.o
clang -flto -fprofile-instr-generate -c 2.cpp -o 2.o
llvm-link -o a.o 1.o 1.o 2.o

error: Linking COMDATs named '__profc__Z1fv': nodeduplicate has been violated!

This is a reduction from a large application (game) from one of our licensees.
Not using LTO works fine.

[petrhosek]

Can you explain your setup a bit more. What do you mean by "Not using LTO works fine"? I assume that in that case, you aren't using llvm-link, but a linker such as lld? Is there a reason for using llvm-link instead of linker in the LTO case?

I think the problem is that llvm-link implements a slightly different semantics from traditional linkers. If I use lld with this reproducer, even in the LTO mode it works fine.

[wolfy1961]

Yeah, sorry, I didn't provide enough context. We found this problem with a couple of games using our PS4 toolchain, which uses a proprietary linker and, for LTO, a proprietary tool that is invoked by the linker and uses LTO.dll (on Windows of course). What I meant with "does not occur with LTO" was that a straight compile-and-link without -flto produces a valid executable, indicating that the input is valid.

With the current upstream version I was only able to reproduce with llvm-link and llvm-lto. Using lld did not fail for me either. I'm hoping that this is enough to go on.

[petrhosek]

I have uploaded https://reviews.llvm.org/D108689 as one potential solution.

[petrhosek]

mentioned in issue #51040

[Endilll]

Solution has landed.