[llvm-bugs] [Bug 35477] New: wrong ASM for attribute naked with build option O0
https://bugs.llvm.org/show_bug.cgi?id=35477
Bug ID: 35477
Summary: wrong ASM for attribute naked with build option O0
Product: new-bugs
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: yejun@intel.com
CC: llvm-bugs@lists.llvm.org
I narrowed down this issue on ubuntu 16.04 x64 on Intel CPU.
the issue only happens with build option -O0, there is no issue with -O1/O2.
Here is the source code, please ignore the meaning of code, it is just used to
show the issue.
fun.cpp:
void __attribute__((naked,noinline)) myfun(int a, int b, int* c, char* d)
{
__asm__ volatile( \
"mov %%fs:0, %%rax\n"
\
"mov %P[tls](%%rax), %%rax\n" \
"test %%rax, %%rax\n" \
"je 1f\n" \
"jmp *%P[api](%%rax)\n" \
"1:\n" \
"retq\n"
\
: \
: [tls] "i" (5),
\
[api] "i" (6)
\
: "cc", "%rdi", "%rsi", "%rdx", "%rcx", "%r8", "%r9", \
"%xmm0", "%xmm1", "%xmm2", "%xmm3", "%xmm4", "%xmm5", \
"%xmm6", "%xmm7" \
);
}
And build the code with:
/work/llvm_dist/llvm50/bin/clang++ -g -O0 -shared -fPIC -o libfun.so fun.cpp
Then, run:
objdump -d libfun.so
We can see the asm of myfun:
0620 <_Z5myfuniiPiPc>:
620: 89 7d fcmov%edi,-0x4(%rbp)
623: 89 75 f8mov%esi,-0x8(%rbp)
626: 48 89 55 f0 mov%rdx,-0x10(%rbp)
62a: 48 89 4d e8 mov%rcx,-0x18(%rbp)
62e: 64 48 8b 04 25 00 00mov%fs:0x0,%rax
635: 00 00
637: 48 8b 40 05 mov0x5(%rax),%rax
63b: 48 85 c0test %rax,%rax
63e: 0f 84 03 00 00 00 je 647 <_Z5myfuniiPiPc+0x27>
644: ff 60 06jmpq *0x6(%rax)
647: c3 retq
When myfun is called, the %rbp and %rsp are not saved, it is still in the stack
of the caller function, so the first 4 instructions overwrite the data in the
stack. This is not correct.
As with -O2 build option, the first 4 instructions are not generated, and so it
works.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35419] False negative on post-increment of uninitialized variable
https://bugs.llvm.org/show_bug.cgi?id=35419 Roman Lebedev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35478] New: Sections with linker-script added contents are treated as zero-size for RELRO processing
https://bugs.llvm.org/show_bug.cgi?id=35478
Bug ID: 35478
Summary: Sections with linker-script added contents are treated
as zero-size for RELRO processing
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
This is a problem with r318924, which I discovered when I was trying to rebase
https://reviews.llvm.org/D38361.
The change added isOutputSectionZeroSize(), which is called during the loop for
assigning segments to relro. By this point, the section Size (both for regular
and synthetic sections) field is not final. They are only final once
assignAddresses() has been called. If a linker script contains a section
assignment with BYTE-style commands, or Dot assignments, such as either of the
two below, it will still be treated as empty, and consequently could end up
being allocated to the relro segment.
Example directives:
.foo : { . += 1; *(.foo) }
.bar : { BYTE(1); *(.bar) }
To reproduce, modify the test in ELF/relro-non-contiguous-zerosize.s such that
the ".zero_size" section in the linker script has one of the above, then
observe that it is still in the RELRO segment in the output.
This does not affect all SyntheticSections, because some do not use Size in
their empty() function, but some do. It does affect all other sections.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35479] New: more efficient code for x % C == 0
https://bugs.llvm.org/show_bug.cgi?id=35479
Bug ID: 35479
Summary: more efficient code for x % C == 0
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: jay.f...@gmail.com
CC: llvm-bugs@lists.llvm.org
Given:
int f(unsigned x) { return x % 25 == 0; }
clang -O3 currently (svn r319159) generates:
movl%edi, %eax
imulq $1374389535, %rax, %rax # imm = 0x51EB851F
shrq$35, %rax
leal(%rax,%rax,4), %eax
leal(%rax,%rax,4), %ecx
xorl%eax, %eax
cmpl%ecx, %edi
sete%al
Following Hacker's Delight 10-16 "Test for Zero Remainder after Division by a
Constant" it would be more efficient to generate:
imull $-1030792151, %edi, %ecx # imm = 0xC28F5C29
xorl%eax, %eax
cmpl$171798692, %ecx# imm = 0xA3D70A4
setb%al
i.e. as if the source had been:
int f(unsigned x) { return x * 0xC28F5C29 <= 0x0A3D70A3; }
The code is similar, but slightly more complicated, for even divisors, and for
signed division.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35480] New: Failure to hit a breakpoint in global constructors in a shared library
https://bugs.llvm.org/show_bug.cgi?id=35480 Bug ID: 35480 Summary: Failure to hit a breakpoint in global constructors in a shared library Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: ezemt...@google.com Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org It's really as simple as it says on the box. The cause is probably that our dynamic linker plugin hooks the shared library load event too late. This affects Linux and probably all other ELF targets as well. I'll commit a TestBreakpointInGlobalConstructors test to demostrate this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35481] New: ARM Thumb1FrameLowering Assertion `PopReg && "Do not know how to get LR"' failed
https://bugs.llvm.org/show_bug.cgi?id=35481 Bug ID: 35481 Summary: ARM Thumb1FrameLowering Assertion `PopReg && "Do not know how to get LR"' failed Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: superjo...@gmail.com CC: llvm-bugs@lists.llvm.org This is LLVM master branch of https://github.com/llvm-project/llvm-project-20170507 commit ff1009fa3858374e7ca5035faa9c85217e957ebb (HEAD -> master, origin/master, origin/HEAD) Author: Simon Pilgrim Date: Wed Nov 29 18:52:20 2017 + [X86][AVX512] Tag 3OP (shuffles, double-shifts and GFNI) instructions scheduler classes zig: /home/andy/Downloads/llvm-project/llvm/lib/Target/ARM/Thumb1FrameLowering.cpp:645: bool llvm::Thumb1FrameLowering::emitPopSpecialFixUp(llvm::MachineBasicBlock&, bool) const: Assertion `PopReg && "Do not know how to get LR"' failed. (gdb) bt #0 0x76938274 in raise () from /nix/store/mjx71lmnlf4psm9942djjcd8b56hyk8b-glibc-2.26-75/lib/libc.so.6 #1 0x76939675 in abort () from /nix/store/mjx71lmnlf4psm9942djjcd8b56hyk8b-glibc-2.26-75/lib/libc.so.6 #2 0x76930cf7 in __assert_fail_base () from /nix/store/mjx71lmnlf4psm9942djjcd8b56hyk8b-glibc-2.26-75/lib/libc.so.6 #3 0x76930da2 in __assert_fail () from /nix/store/mjx71lmnlf4psm9942djjcd8b56hyk8b-glibc-2.26-75/lib/libc.so.6 #4 0x03fe7516 in llvm::Thumb1FrameLowering::emitPopSpecialFixUp (this=0xb5cf500, MBB=..., DoIt=true) at /home/andy/Downloads/llvm-project/llvm/lib/Target/ARM/Thumb1FrameLowering.cpp:645 #5 0x03fe695a in llvm::Thumb1FrameLowering::emitEpilogue (this=0xb5cf500, MF=..., MBB=...) at /home/andy/Downloads/llvm-project/llvm/lib/Target/ARM/Thumb1FrameLowering.cpp:487 #6 0x04ec01b0 in (anonymous namespace)::PEI::insertPrologEpilogCode (this=0xad821e0, Fn=...) at /home/andy/Downloads/llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:973 #7 0x04ebcfbe in (anonymous namespace)::PEI::runOnMachineFunction (this=0xad821e0, Fn=...) at /home/andy/Downloads/llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:210 #8 0x04dd5f84 in llvm::MachineFunctionPass::runOnFunction (this=0xad821e0, F=...) at /home/andy/Downloads/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:62 #9 0x05e7ce9d in llvm::FPPassManager::runOnFunction (this=0xad99bf0, F=...) at /home/andy/Downloads/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1514 #10 0x05e7d014 in llvm::FPPassManager::runOnModule (this=0xad99bf0, M=...) at /home/andy/Downloads/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1535 #11 0x05e7d361 in (anonymous namespace)::MPPassManager::runOnModule (this=0xa944e80, M=...) at /home/andy/Downloads/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1591 #12 0x05e7da15 in llvm::legacy::PassManagerImpl::run (this=0xb5a7640, M=...) at /home/andy/Downloads/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1694 #13 0x05e7dc0d in llvm::legacy::PassManager::run (this=0x7fffcc00, M=...) at /home/andy/Downloads/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1725 #14 0x01bb841d in ZigLLVMTargetMachineEmitToFile (targ_machine_ref=0xa98e5c0, module_ref=0xa98d4f0, filename=0xb503cd0 "./zig-cache/compiler_rt.o", output_type=ZigLLVM_EmitBinary, error_message=0x7fffcef8, is_debug=true) at /home/andy/dev/zig/src/zig_llvm.cpp:165 #15 0x01b3fa01 in do_code_gen (g=0xace38b0) at /home/andy/dev/zig/src/codegen.cpp:4684 #16 0x01b43f63 in codegen_build (g=0xace38b0) at /home/andy/dev/zig/src/codegen.cpp:5841 #17 0x01b89ce3 in build_o_raw (parent_gen=0xa8c1010, oname=0x606a7a4 "compiler_rt", full_path=0xad35590) at /home/andy/dev/zig/src/link.cpp:65 #18 0x01b89e52 in build_compiler_rt (parent_gen=0xa8c1010) at /home/andy/dev/zig/src/link.cpp:91 #19 0x01b8a824 in construct_linker_job_elf (lj=0x7fffd2b0) at /home/andy/dev/zig/src/link.cpp:284 #20 0x01b8c41b in construct_linker_job (lj=0x7fffd2b0) at /home/andy/dev/zig/src/link.cpp:854 #21 0x01b8c780 in codegen_link (g=0xa8c1010, out_file=0x0) at /home/andy/dev/zig/src/link.cpp:919 #22 0x01b90309 in main (argc=15, argv=0x7fffd8d8) at /home/andy/dev/zig/src/main.cpp:840 The use case comes from: https://github.com/skyfex/zig-nrf-demo (sha1 3d9734d238e063492d8fee65c8f8ac6e05a86d8c) zig (https://github.com/zig-lang/zig/) llvm6 branch with cmake option -DZIG_FORCE_EXTERNAL_LLD=ON zig build-exe --static --target-os freestanding --target-arch thumb --target-environ eabihf --assembly gcc_startup_nrf51.S --linker-script nrf51_xxaa.ld --verbose-link --verbose-llvm-ir test.zig when I run the IR through clang directly, it produces an .o file: andy
[llvm-bugs] [Bug 35482] New: ThinLTO hits llvm_unreachable in MCStreamer::BeginCOFFSymbolDef with win32 asm
https://bugs.llvm.org/show_bug.cgi?id=35482
Bug ID: 35482
Summary: ThinLTO hits llvm_unreachable in
MCStreamer::BeginCOFFSymbolDef with win32 asm
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dma...@mozilla.com
CC: llvm-bugs@lists.llvm.org
clang version 6.0.0 (trunk 318877)
Target: i686-pc-windows-msvc
Reduced from xptcstubs.cpp in the Mozilla tree:
$ cat x.cpp
asm(".text\n\t"
".align 4\n\t"
".globl \"?Stub0@nsXPTCStubBase@@UAG?AW4nsresult@@XZ\"\n\t"
".def \"?Stub0@nsXPTCStubBase@@UAG?AW4nsresult@@XZ\"; \n\t"
".scl 2\n\t"
".type 46\n\t"
".endef\n\t"
"\"?Stub0@nsXPTCStubBase@@UAG?AW4nsresult@@XZ\":\n\t"
"mov $0, %ecx\n\t");
$ clang-cl -c x.cpp && echo works fine
works fine
$ clang-cl -flto=thin -c x.cpp
It hits:
void MCStreamer::BeginCOFFSymbolDef(const MCSymbol *Symbol) {
llvm_unreachable("this directive only supported on COFF targets");
}
Presumably because it's an MCStreamer and not a MCWinCOFFStreamer?
#0 0x016210f0 llvm::MCStreamer::BeginCOFFSymbolDef(class llvm::MCSymbol const
*) e:\source\llvm\lib\mc\mcstreamer.cpp:893:0
#1 0x01679e35 `anonymous namespace'::COFFAsmParser::ParseDirectiveDef
e:\source\llvm\lib\mc\mcparser\coffasmparser.cpp:428:0
#2 0x01679525 llvm::MCAsmParserExtension::HandleDirective(class llvm::MCAsmParserExtension *,class
llvm::StringRef,class llvm::SMLoc)
e:\source\llvm\include\llvm\mc\mcparser\mcasmparserextension.h:39:0
#3 0x0166af4c `anonymous namespace'::AsmParser::parseStatement
e:\source\llvm\lib\mc\mcparser\asmparser.cpp:1886:0
#4 0x016575f6 `anonymous namespace'::AsmParser::Run
e:\source\llvm\lib\mc\mcparser\asmparser.cpp:892:0
#5 0x020a4839 llvm::ModuleSymbolTable::CollectAsmSymbols(class llvm::Module
const &,class llvm::function_ref)
e:\source\llvm\lib\object\modulesymboltable.cpp:195:0
#6 0x030aa6d1 llvm::buildModuleSummaryIndex(class llvm::Module const &,class
std::function,class llvm::ProfileSummaryInfo *)
e:\source\llvm\lib\analysis\modulesummaryanalysis.cpp:405:0
#7 0x030adc3d llvm::ModuleSummaryIndexWrapperPass::runOnModule(class
llvm::Module &) e:\source\llvm\lib\analysis\modulesummaryanalysis.cpp:572:0
#8 0x0141b38f `anonymous namespace'::MPPassManager::runOnModule
e:\source\llvm\lib\ir\legacypassmanager.cpp:1591:0
#9 0x0141ac98 llvm::legacy::PassManagerImpl::run(class llvm::Module &)
e:\source\llvm\lib\ir\legacypassmanager.cpp:1695:0
#10 0x019e3ee7 `anonymous namespace'::EmitAssemblyHelper::EmitAssembly
e:\source\llvm\tools\clang\lib\codegen\backendutil.cpp:790:0
#11 0x019e510f clang::EmitBackendOutput(class clang::DiagnosticsEngine &,class
clang::HeaderSearchOptions const &,class clang::CodeGenOptions const &,class
clang::TargetOptions const &,class clang::LangOptions const &,class
llvm::DataLayout const &,class llvm::Module *,enum clang::BackendAction,class
std::unique_ptr >)
e:\source\llvm\tools\clang\lib\codegen\backendutil.cpp:1165:0
#12 0x031e62b9 clang::BackendConsumer::HandleTranslationUnit(class
clang::ASTContext &)
e:\source\llvm\tools\clang\lib\codegen\codegenaction.cpp:292:0
#13 0x0241fefb clang::ParseAST(class clang::Sema &,bool,bool)
e:\source\llvm\tools\clang\lib\parse\parseast.cpp:162:0
#14 0x01d1367f clang::ASTFrontendAction::ExecuteAction(void)
e:\source\llvm\tools\clang\lib\frontend\frontendaction.cpp:998:0
#15 0x01d1356f clang::FrontendAction::Execute(void)
e:\source\llvm\tools\clang\lib\frontend\frontendaction.cpp:901:0
#16 0x01ce4e9c clang::CompilerInstance::ExecuteAction(class
clang::FrontendAction &)
e:\source\llvm\tools\clang\lib\frontend\compilerinstance.cpp:992:0
#17 0x01d856b1 clang::ExecuteCompilerInvocation(class clang::CompilerInstance
*)
e:\source\llvm\tools\clang\lib\frontendtool\executecompilerinvocation.cpp:252:0
#18 0x00ead6c2 cc1_main(class llvm::ArrayRef,char const *,void *)
e:\source\llvm\tools\clang\tools\driver\cc1_main.cpp:221:0
#19 0x00ea84d7 ExecuteCC1Tool
e:\source\llvm\tools\clang\tools\driver\driver.cpp:309:0
#20 0x00eaac0e main e:\source\llvm\tools\clang\tools\driver\driver.cpp:388:0
#21 0x030590a3 _scrt_common_main_seh
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253:0
#22 0x74e68654 BaseThreadInitThunk (C:\WINDOWS\System32\KERNEL32.DLL+0x18654)
#23 0x77d14a47 __RtlUserThreadStart (C:\WINDOWS\SYSTEM32\ntdll.dll+0x64a47)
#24 0x77d14a17 _RtlUserThreadStart (C:\WINDOWS\SYSTEM32\ntdll.dll+0x64a17)
clang-cl.exe: error: clang frontend command failed due to signal (use -v to see
invocation)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35483] New: clang-cl /MDd fails to compile vector with a custom allocator
https://bugs.llvm.org/show_bug.cgi?id=35483
Bug ID: 35483
Summary: clang-cl /MDd fails to compile vector with a custom
allocator
Product: clang
Version: trunk
Hardware: PC
OS: other
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: veronika.levkev...@gmail.com
CC: llvm-bugs@lists.llvm.org
clang-cl.exe fails to compile std::vector with a custom allocator when /MDd is
provided as an argument. The issue seems to be triggered by the _DEBUG define.
Code sample to reproduce the issue:
===
#include
template
class fuzzer_allocator: public std::allocator {
public:
template
struct rebind { typedef fuzzer_allocator other; };
};
int some_func() {
std::vector> v;
return v.size();
}
===
"clang-cl.exe /MDd repro.cc" gives the following output:
In file included from .\repro.cc:2:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\include\vector(555,12):
error: no matching constructor for initialization of
'std::_Vector_alloc > >::_Alproxy' (aka
'(anonymous namespace)::fuzzer_allocator')
_Alproxy _Proxy_allocator(_Getal());
^
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\include\vector(506,3):
note: in instantiation of member function
'std::_Vector_alloc > >::_Free_proxy' requested
here
_Free_proxy();
^
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\include\vector(683,2):
note: in instantiation of member function
'std::_Vector_alloc > >::~_Vector_alloc'
requested here
vector() _NOEXCEPT_COND(is_nothrow_default_constructible<_Alty>::value)
^
.\repro.cc(15,43): note: in instantiation of member function 'std::vector >::vector' requested here
std::vector> v;
^
.\repro.cc(7,9): note: candidate constructor (the implicit copy constructor)
not viable: no known conversion from 'fuzzer_allocator' to 'const
fuzzer_allocator' for 1st argument
class fuzzer_allocator: public std::allocator {
^
.\repro.cc(7,9): note: candidate constructor (the implicit move constructor)
not viable: no known conversion from 'fuzzer_allocator' to
'fuzzer_allocator' for 1st argument
.\repro.cc(7,9): note: candidate constructor (the implicit default
constructor) not viable: requires 0 arguments, but 1 was provided
===
The same code compiles fine when /MDd is not provided.
OS version: Windows 10 Enterprise 1607
MSVC C++ version: 14.11.25503
clang version 6.0.0 (trunk 318667)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35358] GlobalISel: Assertion `SizeInBits != 0 && "invalid zero-sized type"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35358 Amara Emerson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Amara Emerson --- Fixed in r319465. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35347] AArch64 switching to GlobalISel by default for O0
https://bugs.llvm.org/show_bug.cgi?id=35347 Bug 35347 depends on bug 35358, which changed state. Bug 35358 Summary: GlobalISel: Assertion `SizeInBits != 0 && "invalid zero-sized type"' failed. https://bugs.llvm.org/show_bug.cgi?id=35358 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35484] New: Debug server can't be built on High Sierra
https://bugs.llvm.org/show_bug.cgi?id=35484 Bug ID: 35484 Summary: Debug server can't be built on High Sierra Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org [1/262] Linking CXX executable bin/debugserver FAILED: bin/debugserver : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -Wno-gnu-zero-variadic-macro-arguments -Wno-zero-length-array -Wno-extended-offsetof -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,/Users/davide/work/llvm/llvm/tools/lldb/tools/debugserver/source/../resources/lldb-debugserver-Info.plist tools/lldb/tools/debugserver/source/CMakeFiles/debugserver.dir/debugserver.cpp.o -o bin/debugserver -Wl,-rpath,@loader_path/../lib lib/liblldbDebugserverCommon.a -framework Cocoa -framework CoreFoundation -framework Foundation lib/liblldbDebugserverArchSupport.a lib/liblldbDebugserverDarwin_DarwinLog.a -lcompression && cd /Users/davide/work/llvm/build/bin && /usr/local/Cellar/cmake/3.10.0/bin/cmake -E env CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate codesign --force --sign lldb_codesign /Users/davide/work/llvm/build/bin/debugserver error: The specified item could not be found in the keychain. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35484] Debug server can't be built on High Sierra
https://bugs.llvm.org/show_bug.cgi?id=35484 Greg Clayton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||clayb...@gmail.com --- Comment #1 from Greg Clayton --- You need to create the lldb_codesign code signing certificate by following the instructions at: svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35484] Debug server can't be built on High Sierra
https://bugs.llvm.org/show_bug.cgi?id=35484 Davide Italiano changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Davide Italiano --- Reopening. The error message is particularly cryptic, in particular for somebody who doesn't understand how the code signing mechanism works. FWIW, I think this, rather than failing at link time can fail at configure time (if possible). Then, it should point to the instructions you linked. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35485] New: clang is not resilient to source files changing length underneath it
https://bugs.llvm.org/show_bug.cgi?id=35485 Bug ID: 35485 Summary: clang is not resilient to source files changing length underneath it Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: caus...@gmail.com CC: llvm-bugs@lists.llvm.org At Facebook, engineers have reported that clang will sometimes segfault if the developer saves a file in the middle of compilation. While tracking down an unrelated bug, I noticed that this appears to be because SourceManager has UserFilesAreVolatile set to false which eventually causes MemoryBuffer::getOpenFile to be called with isVolatile false, which memory maps it. When memory mapping a file whose length has changed underneath it, accessing pages beyond the end of the backing file results in a SIGBUS. In addition, I believe line number computation expects a trailing nul byte, which is implemented by mapping one byte larger than the file (assuming the file is not exactly on a page boundary). But if the file has since expanded, that byte is no longer null, and clang SIGSEGVs while computing line numbers. It seems like UserFilesAreVolatile should be set true for non-system files. #35333 looks related. And possibly #20880. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28958] [memcpyopt] Memcpy-memcpy dependence isn't detected across basic blocks.
https://bugs.llvm.org/show_bug.cgi?id=28958 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dan Gohman --- This is now fixed in r319482 and r319483. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35435] Member access to incomplete type from dllimport
https://bugs.llvm.org/show_bug.cgi?id=35435 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- r319386 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35486] New: Compiler crash when collapsing two loops in omp distribute parallel for
https://bugs.llvm.org/show_bug.cgi?id=35486
Bug ID: 35486
Summary: Compiler crash when collapsing two loops in omp
distribute parallel for
Product: OpenMP
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: jo...@udel.edu
CC: llvm-bugs@lists.llvm.org
I am trying to compile this code and it crashes during compilation time. The
problem seems to be related with the initialization of the innerloop with the
outer loop.
#include
#include
#include
int main(){
int n, npl = 1000;
int arr[1000];
#pragma omp target data map (from: arr)
#pragma omp target teams map (alloc: arr)
#pragma omp distribute parallel for collapse(2) private(n)
for (int nonsense = 0; nonsense < 4; nonsense++) {
for (int n = (1 + nonsense); n <= npl; n+=4) {
arr[n] = 0;
}
}
}
My clang version
> clang --version
clang version 3.8.0 (ibmgithub:/CORAL-LLVM-Compilers/clang.git
fc73231cc1447f6163740eb12b6f3fd5c69c6a1a) (ibmgithub:/CORAL-LLVM-
Compilers/llvm.git 47cc905855d51360bcc523d2d290395073d87560)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
The compilation command I am using is:
> clang -std=c99 -c -O3 -g -fopenmp -fopenmp-targets=nvptx64-nvida-cuda
bugClang.c
Here is the output when it crashes. I am also attaching the core file.
DeclRefExpr for Decl not entered in LocalDeclMap?
UNREACHABLE executed at
/home/compteam/slave0/build_folder_trunk_ibm_inline/src/tools/clang/lib/CodeGen/CGExpr.cpp:2217!
#0 0x11bb7148 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11bb7148)
#1 0x11bb76b8 PrintStackTraceSignalHandler(void*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11bb76b8)
#2 0x11bb7a84 SignalHandler(int)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11bb7a84)
#3 0x10050478 0x478 __GI_abort
#4 0x10050478
#5 0x10050478 llvm::llvm_unreachable_internal(char const*, char const*,
unsigned int) (+0x478)
#6 0x10450d70
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*)
(/lib64/libc.so.6+0x40d70)
#7 0x11b586ac clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr
const*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11b586ac)
#8 0x11fe6fdc
clang::CodeGen::CodeGenFunction::EmitCheckedLValue(clang::Expr const*,
clang::CodeGen::CodeGenFunction::TypeCheckKind)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11fe6fdc)
#9 0x11fda34c clang::StmtVisitorBase::Visit(clang::Stmt*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11fda34c)
#10 0x11fe3f38 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x11fe3f38)
#11 0x1202bf6c clang::StmtVisitorBase::Visit(clang::Stmt*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x1202bf6c)
#12 0x12035c00 (anonymous
namespace)::ScalarExprEmitter::EmitBinOps(clang::BinaryOperator const*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x12035c00)
#13 0x12029b1c clang::StmtVisitorBase::Visit(clang::Stmt*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x12029b1c)
#14 0x120321c0 clang::StmtVisitorBase::Visit(clang::Stmt*)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc566co7f345rfynat/bin/clang-3.8+0x120321c0)
#15 0x1202a4d8
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
(/autofs/nccs-svm1_sw/summitdev/.swci/0-core/opt/spack/20170405/linux-rhel7-ppc64le/gcc-4.8.5/clang-20170925-mfo7hvcvzzejibsc56
[llvm-bugs] [Bug 35440] lld's .hash and .gnu.hash are bigger than gold's
https://bugs.llvm.org/show_bug.cgi?id=35440 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Rui Ueyama --- Fixed in https://reviews.llvm.org/rL319503. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35487] New: Poor code generation for rotates
https://bugs.llvm.org/show_bug.cgi?id=35487
Bug ID: 35487
Summary: Poor code generation for rotates
Product: libraries
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: fabi...@radgametools.com
CC: llvm-bugs@lists.llvm.org
This: https://godbolt.org/g/b2t1a9
unsigned long f(unsigned long x, int amt)
{
x += (x << amt) | (x >> (64 - amt));
return x & 0xu;
}
unsigned long g(unsigned long x, int amt)
{
x += (x << amt) | (x >> (64 - amt));
return x;
}
produces:
f(unsigned long, int): # @f(unsigned long, int)
mov rax, rdi
mov ecx, esi
shl rax, cl
mov ecx, 64
sub ecx, esi
mov rdx, rdi
shr rdx, cl
or edx, eax
add edi, edx
mov rax, rdi
ret
g(unsigned long, int): # @g(unsigned long, int)
mov rax, rdi
mov ecx, esi
rol rax, cl
lea rax, [rax + rdi]
ret
Found while investigating a significant perf difference between LLVM and gcc on
a hash function. (Yes, "amt" is variable in the code in question.)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35488] New: [Meta] tracking test suite failure on Mac OS
https://bugs.llvm.org/show_bug.cgi?id=35488 Bug ID: 35488 Summary: [Meta] tracking test suite failure on Mac OS Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org I ran lldb on a pristine, freshly installed (stock) Mac OS High Sierra. This is the current status of the test suite (ran through `ninja check-lldb`): === Test Result Summary === Test Methods: 2659 Reruns:6 Success:1682 Expected Failure:100 Failure: 8 Error: 510 Exceptional Exit: 0 Unexpected Success: 37 Skip:320 Timeout: 2 Expected Timeout: 0 This status makes slightly harder to push non-trivial changes in lldb, because it's not entirely obvious how to track regressions. Let's open this PR to keep track. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35489] New: +g and +X inline asm constraints generate worse code than +r
https://bugs.llvm.org/show_bug.cgi?id=35489
Bug ID: 35489
Summary: +g and +X inline asm constraints generate worse code
than +r
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Testcase:
int f(int n) { asm volatile("":"+g"(n)); return n; }
int k = f(4) + 1;
Targeting x86_64, we get this mess:
movl$4, -4(%rsp)
movl$4, %eax
#APP
#NO_APP
movl%eax, -4(%rsp)
addl$1, %eax
movl%eax, k(%rip)
A "+r" constraint, which should be *more* constraining (and thus produce worse
code in general) gives this:
movl$4, %eax
#APP
#NO_APP
addl$1, %eax
movl%eax, k(%rip)
GCC produces the better code for both constraints.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4493 in oss-fuzz: llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-12-01 Type: Bug New issue 4493 by ClusterFuzz-External: llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4493 Detailed report: https://oss-fuzz.com/testcase?key=4784634723303424 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcebf18f28 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711140614:201711141648 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4784634723303424 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35490] New: llvm-cov: Wrong coverage with multiple binaries and shared code
https://bugs.llvm.org/show_bug.cgi?id=35490
Bug ID: 35490
Summary: llvm-cov: Wrong coverage with multiple binaries and
shared code
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dennis.fels...@sap.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19501
--> https://bugs.llvm.org/attachment.cgi?id=19501&action=edit
run.sh
Even with differently named functions the combined coverage seems wrong. In the
attached example I would expect w() in w.hpp to be covered.
If the implementation of w() is changed to
if (i == 0) {
std::cout << "foo" << std::endl;
}
There is a warning from llvm-cov:
warning: 1 functions have mismatched data
But in the attached example llvm-cov does not warn and shows wrong coverage for
w() instead.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
