Andrew, with what OS and compiler are you seeing this?

Linux, standart Clang toolchain like here:

atischenko@ip-172-31-21-62:~/workspaces$ cat new-workspace-avt77-make.sh

mkdir build
svn co https://avt77@llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools
svn co https://avt77@llvm.org/svn/llvm-project/cfe/trunk clang
cd ../../build
cmake -DLLVM_ENABLE_EXPENSIVE_CHECKS -DCMAKE_BUILD_TYPE=Debug ../llvm
cmake -E time make -j 4

The last line creates TableGen and trys to use it but can't because of the issue.

So you're building with gcc? What version?

Also, please can you include the error message you see from the Tablegen build.

Yes, I used gcc to create TableGe. I'll give you all necessary info asap.

-- The CXX compiler identification is GNU 5.4.0

And now I got the following:

Scanning dependencies of target LibOptionsTableGen
[ 23%] Building Options.inc...
[ 23%] Building Options.inc...
[ 23%] Building Intrinsics.inc...
[ 23%] Updating Options.inc...
[ 23%] Updating Options.inc...
[ 23%] Built target DllOptionsTableGen
[ 23%] Built target LibOptionsTableGen
Scanning dependencies of target clang-tablegen-targets
[ 23%] Built target clang-tablegen-targets
Scanning dependencies of target llvm-mt
[ 23%] Building CXX object tools/llvm-mt/CMakeFiles/llvm-mt.dir/llvm-mt.cpp.o
Scanning dependencies of target llvm-rc
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/llvm-rc.cpp.o
[ 23%] Updating Options.inc...
[ 23%] Built target ClangDriverOptions
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceFileWriter.cpp.o
/usr/include/c++/5/debug/safe_container.h:86:error: attempt to self move
    assign.

Objects involved in the operation:
sequence "this" @ 0x0x7ffbdc9c6288 {
}
../../../bin/llvm-tblgen[0x9a1271]
../../../bin/llvm-tblgen[0x9a1304]
../../../bin/llvm-tblgen[0x99f544]
../../../bin/llvm-tblgen[0x9a0c87]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7ffbddb79390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7ffbdcd0a428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7ffbdcd0c02a]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNK11__gnu_debug16_Error_formatter8_M_errorEv+0x155)[0x7ffbdd672f95]
../../../bin/llvm-tblgen[0x64dd86]
../../../bin/llvm-tblgen[0x64a7b5]
../../../bin/llvm-tblgen[0x64a815]
../../../bin/llvm-tblgen[0x64a99c]
../../../bin/llvm-tblgen[0x64ab02]
../../../bin/llvm-tblgen[0x6463b7]
../../../bin/llvm-tblgen[0x64156f]
../../../bin/llvm-tblgen[0x633d83]
../../../bin/llvm-tblgen[0x630a8d]
../../../bin/llvm-tblgen[0x7c0a1a]
../../../bin/llvm-tblgen[0x7c4581]
../../../bin/llvm-tblgen[0x89b258]
../../../bin/llvm-tblgen[0x9dcb77]
../../../bin/llvm-tblgen[0x89b918]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffbdccf5830]
../../../bin/llvm-tblgen[0x4096e9]
Stack dump:
0.      Program arguments: ../../../bin/llvm-tblgen -gen-intrinsic -I /home/atischenko/workspaces/pr35548-tg-warns/llvm/include/llvm/IR -I /home/atischenko/workspaces/pr35548-tg-warns/llvm/include /home/atischenko/workspaces/pr35548-tg-warns/llvm/include/llvm/IR/Intrinsics.td -o /home/atischenko/workspaces/pr35548-tg-warns/build/include/llvm/IR/Intrinsics.inc.tmp
Aborted (core dumped)
include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:161: recipe for target 'include/llvm/IR/Intrinsics.inc.tmp' failed
make[2]: *** [include/llvm/IR/Intrinsics.inc.tmp] Error 134
CMakeFiles/Makefile2:976: recipe for target 'include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all' failed
make[1]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptCppFilter.cpp.o
[ 23%] Linking CXX executable ../../bin/llvm-mt
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptParser.cpp.o
[ 23%] Built target llvm-mt
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptStmt.cpp.o
[ 23%] Building CXX object tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptToken.cpp.o
[ 23%] Linking CXX executable ../../bin/llvm-rc
[ 23%] Built target llvm-rc
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

With gdb I saw usage of sort but I'm not sure it's a sort problem. Most probably there is an attempt to use destructed objects inside sort. Not long ago I had the very similar problem when I tried to sort FunctionDecl* objects to print out the compilation times.

@mgrang is this something you've seen at all?

I haven't seen this in my testing. However, I can reproduce the failure using the steps Andrew provided.

It seems the crash is coming out of this particular instance of llvm:sort in utils/TableGen/CodeGenTarget.cpp:

CodeGenIntrinsicTable::CodeGenIntrinsicTable(const RecordKeeper &RC,
                                             bool TargetOnly) {
...

  llvm::sort(Intrinsics.begin(), Intrinsics.end(),
             [](const CodeGenIntrinsic &LHS, const CodeGenIntrinsic &RHS) {
               return std::tie(LHS.TargetPrefix, LHS.Name) <
                      std::tie(RHS.TargetPrefix, RHS.Name);
...
}

I didn't get a chance to look into this more closely but if I remove the comparator then it seems to go fine.

What does default comparator do? Simply compares 2 pointers? If yes it means it does not deal with underlying objects and that looks very similar to what I saw with FunctionDecl* pointers (see above).

*** Bug 38172 has been marked as a duplicate of this bug. ***

According to https://stackoverflow.com/questions/22915325/avoiding-self-assignment-in-stdshuffle this is caused by an overly aggressive assertion in libstdc++.

I just tried copying the libc++ of std::shuffle() as llvm::shuffle() and using that instead and it appears to fix the problem. If this is considered a reasonable solution I can upload a patch to phabricator.

(In reply to Alexander Richardson from comment #11)
> According to
> https://stackoverflow.com/questions/22915325/avoiding-self-assignment-in-
> stdshuffle this is caused by an overly aggressive assertion in libstdc++.
> 
> I just tried copying the libc++ of std::shuffle() as llvm::shuffle() and
> using that instead and it appears to fix the problem. If this is considered
> a reasonable solution I can upload a patch to phabricator.

Yes thank you, I think that its worth raising as a patch to be discussed by a broader audience.

This issue still exists.

Possible fix https://reviews.llvm.org/D98167

Should be fixed by https://github.com/llvm/llvm-project/commit/35bf23e965508a6ca00009ca45ba882d1ba7808c