[compiler-rt] r362676 - [Profile]: Add runtime interface to specify file handle for profile data.

Wed Jun 12 14:21:04 PDT 2019

What compiler are you using to compile stage 1?

I get a different failure during stage 2:

[1864/2833] Building DiagnosticParseKinds.inc...
FAILED: tools/clang/include/clang/Basic/DiagnosticParseKinds.inc
cd /local/ssd1/sajjadm/llvm-project/stage2 &&
/local/ssd1/sajjadm/llvm-project/stage2/bin/clang-tblgen
-gen-clang-diags-defs -clang-component=Parse -I
/local/ssd1/sajjadm/llvm-project/clang/include/clang/Basic -I
/local/ssd1/sajjadm/llvm-project/llvm/include
/local/ssd1/sajjadm/llvm-project/clang/include/clang/Basic/Diagnostic.td -o
tools/clang/include/clang/Basic/DiagnosticParseKinds.inc -d
tools/clang/include/clang/Basic/DiagnosticParseKinds.inc.d
pure virtual method called
terminate called without an active exception

I made a small tweak to the source code (commented out the new function's
declaration in InstrProfiling.h) and with that stage 2 compiled cleanly but
then stage 3 had a similar problem:

FAILED: lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o
/local/ssd1/sajjadm/llvm-project/stage2/bin/clang++  -DGTEST_HAS_RTTI=0
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/Demangle
-I/local/ssd1/sajjadm/llvm-project/llvm/lib/Demangle -I/usr/include/libxml2
-Iinclude -I/local/ssd1/sajjadm/llvm-project/llvm/include -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
 -fno-exceptions -fno-rtti -MD -MT
lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o -MF
lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o.d -o
lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o -c
/local/ssd1/sajjadm/llvm-project/llvm/lib/Demangle/Demangle.cpp
pure virtual method called
terminate called without an active exception

My stage 1 compiler is GCC 7.3.0

On Wed, Jun 12, 2019 at 1:42 AM Hans Wennborg <hans at chromium.org> wrote:

> We noticed in Chromium (we're trying to start building Clang itself
> with PGO) that this change is causing IR-instrumented Clang to become
> crashy. (+gbiv in case he saw similar issues)
>
> I've reverted it (and the follow-up with test cases) in r363134.
>
> To reproduce on a Linux workstation, in the llvm monorepo checked out
> at c1867557d93d622f761b57af6e66e3e518bc0b9f / r362676
>
> $ ( mkdir build.stage1 && cd build.stage1 && cmake -GNinja
> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;compiler-rt"
> ../llvm && ninja )
> $ ( mkdir build.stage2 && cd build.stage2 &&
> CC=${PWD}/../build.stage1/bin/clang
> CXX=${PWD}/../build.stage1/bin/clang++ cmake -GNinja
> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
> -DLLVM_BUILD_INSTRUMENTED=IR ../llvm && ninja clang )
> $ ( mkdir build.stage3 && cd build.stage3 &&
> CC=${PWD}/../build.stage2/bin/clang
> CXX=${PWD}/../build.stage2/bin/clang++ cmake -GNinja
> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang ../llvm &&
> ninja clang )
>
> The instrumented Clang now crashes pretty soon, in this case:
>
> [5/2833] Building CXX object
> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
> FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
> /work/llvm.monorepo/build.stage2/bin/clang++  -DGTEST_HAS_RTTI=0
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS -Ilib/Support
> -I/work/llvm.monorepo/llvm/lib/Support -I/usr/include/libxml2
> -Iinclude -I/work/llvm.monorepo/llvm/include -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
>  -fno-exceptions -fno-rtti -MD -MT
> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -MF
> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o.d -o
> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -c
> /work/llvm.monorepo/llvm/lib/Support/ConvertUTF.cpp
>
> /work/llvm.monorepo/build.stage2/bin/clang++(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
> /work/llvm.monorepo/build.stage2/bin/clang++[0x2b98c3f]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7f8ad19a03a0]
> /work/llvm.monorepo/build.stage2/bin/clang++[0x5817d2b]
> /work/llvm.monorepo/build.stage2/bin/clang++[0x5817c42]
> /work/llvm.monorepo/build.stage2/bin/clang++[0x58172e2]
> /lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7f8ad04942ec]
> /lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7f8ad049441a]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7f8ad047e532]
> /work/llvm.monorepo/build.stage2/bin/clang++(_start+0x2a)[0xa2b75a]
>
> It's interesting to see libpthread.so on the stack. Maybe that
> suggests recursive locking or something?
>
> Trying to recompile just that file with the instrumented Clang works
> fine, the crash doesn't happen every time (which is why I haven't
> caught it in a debugger), but running many compilations in parallel
> reproduces the issue fairly reliably:
>
> $ cd build.stage3
> $ for x in `seq 1 100` ; do ( ../build.stage2/bin/clang++
> -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support
> -I../llvm/lib/Support -Iinclude -I../llvm/include -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
> -fno-exceptions -fno-rtti -c ../llvm/lib/Support/ConvertUTF.cpp -o
> /dev/null && echo OK ) & done
>
>
> /work/llvm.monorepo/build.stage2/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
> /work/llvm.monorepo/build.stage2/bin/clang-9[0x2b98c3f]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7fd08f2bf3a0]
> /work/llvm.monorepo/build.stage2/bin/clang-9[0x5817d2b]
> /work/llvm.monorepo/build.stage2/bin/clang-9[0x5817c42]
> /work/llvm.monorepo/build.stage2/bin/clang-9[0x58172e2]
> /lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7fd08ddb32ec]
> /lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7fd08ddb341a]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7fd08dd9d532]
> /work/llvm.monorepo/build.stage2/bin/clang-9(_start+0x2a)[0xa2b75a]
> clang-9: error: unable to execute command: Segmentation fault
> clang-9: error: clang frontend command failed due to signal (use -v to
> see invocation)
> clang version 9.0.0 (https://github.com/llvm/llvm-project
> c1867557d93d622f761b57af6e66e3e518bc0b9f)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /work/llvm.monorepo/build.stage3/../build.stage2/bin
>
>
> On Thu, Jun 6, 2019 at 8:32 AM Xinliang David Li via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> >
> > Author: davidxl
> > Date: Wed Jun  5 23:35:18 2019
> > New Revision: 362676
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=362676&view=rev
> > Log:
> > [Profile]: Add runtime interface to specify file handle for profile data.
> >
> > Author: Sajjad Mirza
> >
> > Differential Revision: http://reviews.llvm.org/D62541
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190612/19d7ddd7/attachment.html>