[llvm-bugs] [Bug 32832] New: segfault in llvm::FPPassManager::runOnFunction, running X86 FP Stackifier pass
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Apr 27 14:56:15 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=32832
Bug ID: 32832
Summary: segfault in llvm::FPPassManager::runOnFunction,
running X86 FP Stackifier pass
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: peter at cordes.ca
CC: llvm-bugs at lists.llvm.org
While compiling some code with rotates and bswaps (that's what I changed most
recently), I hit a compiler error.
I'm using x86-64 Arch Linux's clang-4.0.0-1 package.
(https://www.archlinux.org/packages/extra/x86_64/clang/).
#0 0x00007f56bf845d88 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/
../lib/libLLVM-4.0.so+0x76fd88)
#1 0x00007f56bf843cae llvm::sys::RunSignalHandlers()
(/usr/bin/../lib/libLLVM-4.0.so+0x76dcae)
#2 0x00007f56bf843dea (/usr/bin/../lib/libLLVM-4.0.so+0x76ddea)
#3 0x00007f56be7c6a90 __restore_rt (/usr/bin/../lib/libc.so.6+0x33a90)
#4 0x00007f56c0fd7f98 (/usr/bin/../lib/libLLVM-4.0.so+0x1f01f98)
#5 0x00007f56c0fda55d (/usr/bin/../lib/libLLVM-4.0.so+0x1f0455d)
#6 0x00007f56c0fdbf4a (/usr/bin/../lib/libLLVM-4.0.so+0x1f05f4a)
#7 0x00007f56bfa9a841 llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/bin/../lib/libLLVM-4.0.so+0x9c4841)
#8 0x00007f56bf91ab32 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/bin/../lib/libLLVM-4.0.so+0x844b32)
#9 0x00007f56bf91abd3 llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/bin/../lib/libLLVM-4.0.so+0x844bd3)
#10 0x00007f56bf91b584 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/bin/../lib/libLLVM-4.0.so+0x845584)
#11 0x000000000078f9eb clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete<llvm::raw_pwrite_stream> >) (/usr/bin/clang-4.0+0x78f9eb)
#12 0x0000000000b5f4b0 (/usr/bin/clang-4.0+0xb5f4b0)
#13 0x0000000000cadaa8 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/bin/clang-4.0+0xcadaa8)
#14 0x0000000000acf56e clang::FrontendAction::Execute()
(/usr/bin/clang-4.0+0xacf56e)
#15 0x0000000000a9ff66
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/bin/clang-4.0+0xa9ff66)
#16 0x0000000000b58022
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/bin/clang-4.0+0xb58022)
#17 0x0000000000746298 cc1_main(llvm::ArrayRef<char const*>, char const*,
void*) (/usr/bin/clang-4.0+0x746298)
#18 0x0000000000742002 main (/usr/bin/clang-4.0+0x742002)
#19 0x00007f56be7b3511 __libc_start_main (/usr/bin/../lib/libc.so.6+0x20511)
#20 0x000000000074417a _start (/usr/bin/clang-4.0+0x74417a)
Stack dump:
0. Program arguments: /usr/bin/clang-4.0 -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name CanvasRenderingContext2d.cc
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu sandybridge -target-feature -sse2 -mllvm
-x86-asm-syntax=intel -momit-leaf-frame-pointer -dwarf-column-info
-debugger-tuning=gdb -coverage-notes-file
/home/peter/src/primity/node-canvas/build/-.gcno -resource-dir
/usr/bin/../lib/clang/4.0.0 -dependency-file
./Release/.deps/Release/obj.target/canvas/src/CanvasRenderingContext2d.o.d.raw
-MT - -D NODE_GYP_MODULE_NAME=canvas -D USING_UV_SHARED=1 -D USING_V8_SHARED=1
-D V8_DEPRECATION_WARNINGS=1 -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D
HAVE_FREETYPE -D HAVE_PANGO -D HAVE_JPEG -D HAVE_GIF -D BUILDING_NODE_EXTENSION
-I /home/peter/.node-gyp/7.7.3/include/node -I /home/peter/.node-gyp/7.7.3/src
-I /home/peter/.node-gyp/7.7.3/deps/uv/include -I
/home/peter/.node-gyp/7.7.3/deps/v8/include -I ../../nan -I /usr/include/cairo
-I /usr/include/pixman-1 -I /usr/include/freetype2 -I /usr/include/libpng16 -I
/usr/include/harfbuzz -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include -I
/usr/include/libdrm -I /usr/include/pango-1.0 -internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/x86_64-pc-linux-gnu
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/4.0.0/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O3 -Wall -Wextra -Wno-unused-parameter
-std=gnu++0x -fdeprecated-macro -fdebug-compilation-dir
/home/peter/src/primity/node-canvas/build -ferror-limit 19 -fmessage-length 0
-pthread -fno-rtti -fobjc-runtime=gcc -fdiagnostics-show-option
-vectorize-loops -vectorize-slp -o - -x c++ ../src/CanvasRenderingContext2d.cc
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'../src/CanvasRenderingContext2d.cc'.
4. Running pass 'X86 FP Stackifier' on function
'@_ZN9Context2d6RotateERKN3Nan20FunctionCallbackInfoIN2v85ValueEEE'
clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
The most recent changes from when it didn't segfault, IIRC, were in
copy1PixRGBAtoNative (called from PutImageData), and adding
Canvas *canvas = context->canvas();
early in PutImageData instead of re-chasing the pointer every time it's used.
(I'm working on speeding up PutImageData and GetImageData in node-canvas,
https://github.com/Automattic/node-canvas/issues/909)
In case it's relevant, in a version that did compile, I noticed that clang
decided *not* to use a ROR instruction to rotate by 8 bits, but instead do two
shifts + and OR, because it wanted to keep one of the shifted values around for
use in an unlikely() branch. i.e. it seriously slowed down the fast path
because of CSE with the slow path, for the scalar version. /facepalm. Extra
MOV instructions for this reason seem to be common for gcc, but clang had
mostly been doing better.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170427/34cff892/attachment.html>
More information about the llvm-bugs
mailing list