clang woes

[ThosRTanner]

I'm doing work on a gnome program on windows 10 and I've been trying to build it for various reasons with clang

If I build with CC=which clang CXX=which clang++ with the MINGW64 packages, the resulting executable performs more or less the same as building with gcc.

Same goes when building with UCRT64 packages

If however I build with the CLANG64 packages the resulting executable suffers dire performance issues. One operation that takes almost no time takes up to 5 seconds. One that takes about 20s under the other setups (it's creating a lot of lines to display in a gtk pane), well, I don't know how long it takes under CLANG64. More than a minute at least.

It's clearly wrong that it takes 20s and that's what I'm trying to alleviate, and I presume the enormous delay is probably the clang build doing something even less efficiently than the normal one, and if I knew what was causing this, I'd be better able to address it.

Nonetheless, I don't think there should be that noticeable a difference in behaviour.

FWIW the project is https://gitlab.gnome.org/GNOME/pan and I'm looking at https://gitlab.gnome.org/GNOME/pan/-/issues/20

[mati865]

I doubt it has anything to do with Clang itself but is probably related to libc++, less likely compiler-rt or libunwind. We would need some profiling results to know what is the problem and report it upstream.

[ThosRTanner]

Profiling (or the lack of being able to get anything useful, like time spent in particular functions, like I'd get with gcov except it doesn't work - there's another issue for that) is what I was trying to get. I'll see if I can persuade --coverage to produce useful information

[mati865]

Unfortunately I have no idea about profiling on Windows, on Linux I'd start with perf and create flamegraph from it.

[ThosRTanner]

Sadly if i build with --coverage, this happens on exit:

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff7fac74ba7 in llvm_gcda_emit_function ()
(gdb) where
#0  0x00007ff7fac74ba7 in llvm_gcda_emit_function ()
#1  0x00007ff7fabbb542 in __llvm_gcov_writeout ()
#2  0x00007ff7fac75b31 in llvm_writeout_and_clear ()
#3  0x00007ffdc34c42d6 in ucrtbase!_execute_onexit_table () from C:\Windows\System32\ucrtbase.dll
#4  0x00007ffdc34c41fb in ucrtbase!_execute_onexit_table () from C:\Windows\System32\ucrtbase.dll
#5  0x00007ffdc34c41b4 in ucrtbase!_execute_onexit_table () from C:\Windows\System32\ucrtbase.dll
#6  0x00007ffdc34d0522 in ucrtbase!exit () from C:\Windows\System32\ucrtbase.dll
#7  0x00007ffdc34d04ab in ucrtbase!exit () from C:\Windows\System32\ucrtbase.dll
#8  0x00007ffdc34d044e in ucrtbase!exit () from C:\Windows\System32\ucrtbase.dll
#9  0x00007ff7fa9e1410 in __tmainCRTStartup () at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:324
#10 0x00007ff7fa9e1156 in WinMainCRTStartup () at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176

which rather puts paid to getting any useful information out of it

This is clang version 14.0.4

[mati865]

I don't get how coverage would help here but you'd probably need also -rtlib=compiler-rt.

[alvinhochun]

The Intel vtune profiler may help (it also understands dwarf debug info).

We hit something similar in Krita. It turned out to be libc++ hitting a slow path doing locale juggling in std::ostringstream, making it orders of magnitude slower. (https://github.com/llvm/llvm-project/issues/56202)