[llvm-bugs] [Bug 27766] Remove exit-on-error from test/CodeGen/BPF/many_args1.ll
https://llvm.org/bugs/show_bug.cgi?id=27766 Diana Picus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Diana Picus --- Committed in r270419 -- 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 27759] [Meta] Remove exit-on-error flag
https://llvm.org/bugs/show_bug.cgi?id=27759 Bug 27759 depends on bug 27766, which changed state. Bug 27766 Summary: Remove exit-on-error from test/CodeGen/BPF/many_args1.ll https://llvm.org/bugs/show_bug.cgi?id=27766 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 27828] Firstprivate in for directive does not work properly.
https://llvm.org/bugs/show_bug.cgi?id=27828
Samuel Antao changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #2 from Samuel Antao ---
Hi Alexey,
Sorry I messed up the repro when I was reducing it. So, here's an updated one
that shows the problem:
#include
int main(void) {
int a = 2;
#pragma omp parallel if(0)
{
#pragma omp for firstprivate(a)
for (int i = 0; i < 1; i++) {
printf(" Hi from first loop --> %d!\n", a);
a += 1;
}
#pragma omp for firstprivate(a)
for (int i = 0; i < 1; i++) {
printf(" Hi from second loop --> %d!\n", a);
a += 1;
}
}
printf(" Final --> %d\n", a);
return 0;
}
I get:
Hi from first loop --> 2!
Hi from second loop --> 3!
Final --> 2
So `a` is privatized in the parallel scope but not for each loop.
Thanks!
Samuel
--
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 27841] New: Compilation triggers a compiler bug - it asked to report to llvm.org
https://llvm.org/bugs/show_bug.cgi?id=27841 Bug ID: 27841 Summary: Compilation triggers a compiler bug - it asked to report to llvm.org Product: clang Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: u...@ll.mit.edu CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Mac OS X 10.11.5, Xcode-7.3.1, Macports-2.3.4. The problem is with Macports-installed clang-3.7 (which was built using Xcode-7.3.1). Here's the screen log: clang++-mp-3.7 -maes -mpclmul -mrdrnd -msse2 -mssse3 -msse4.1 -msse4.2 -std=c++11 -ffunction-sections -fdata-sections -O3 -fPIC -march=native -pipe -c integer.cpp Assertion failed: (BB->getTerminator()->getNumSuccessors() == 1 && "Should have a single succ!"), function SplitEdge, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/llvm-3.7/work/llvm-3.7.1.src/lib/Transforms/Utils/BasicBlockUtils.cpp, line 262. 0 libLLVM-3.7.dylib0x00010ee3a6bf llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 57 1 libLLVM-3.7.dylib0x00010ee3ad0e SignalHandler(int) + 231 2 libsystem_platform.dylib 0x7fff92c6952a _sigtramp + 26 3 libsystem_platform.dylib 0x7fa9738024e8 _sigtramp + 3770257368 4 libsystem_c.dylib0x7fff8c8af6e7 abort + 129 5 libsystem_c.dylib0x7fff8c876df8 basename + 0 6 libLLVM-3.7.dylib0x00010eeb2d23 llvm::SplitBlock(llvm::BasicBlock*, llvm::Instruction*, llvm::DominatorTree*, llvm::LoopInfo*) + 0 7 libLLVM-3.7.dylib0x00010ebb253d (anonymous namespace)::JumpThreading::DuplicateCondBranchOnPHIIntoPred(llvm::BasicBlock*, llvm::SmallVectorImpl const&) + 981 8 libLLVM-3.7.dylib0x00010ebad752 (anonymous namespace)::JumpThreading::runOnFunction(llvm::Function&) + 4938 9 libLLVM-3.7.dylib0x00010e7258e5 llvm::FPPassManager::runOnFunction(llvm::Function&) + 297 10 libLLVM-3.7.dylib0x00010f09f74e (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 1230 11 libLLVM-3.7.dylib0x00010e725dc0 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 628 12 clang0x00010c911a6d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 6301 13 clang0x00010ca28d0c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 510 14 clang0x00010ca9ee7a clang::ParseAST(clang::Sema&, bool, bool) + 393 15 clang0x00010c7c63cf clang::FrontendAction::Execute() + 71 16 clang0x00010c79eebb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 553 17 clang0x00010c7726f6 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3822 18 clang0x00010c76adcd cc1_main(llvm::ArrayRef, char const*, void*) + 1389 19 clang0x00010c770e67 main + 8505 20 libdyld.dylib0x7fff90a385ad start + 1 21 libdyld.dylib0x0086 start + 1868331738 Stack dump: 0.Program arguments: /opt/local/libexec/llvm-3.7/bin/clang -cc1 -triple x86_64-apple-macosx10.11.0 -emit-obj -disable-free -main-file-name integer.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu ivybridge -target-feature -sse4a -target-feature -avx512bw -target-feature +cx16 -target-feature -tbm -target-feature -adx -target-feature -fma4 -target-feature -avx512vl -target-feature -prfchw -target-feature -bmi2 -target-feature -avx512pf -target-feature +fsgsbase -target-feature +avx -target-feature -avx512cd -target-feature -rtm -target-feature +popcnt -target-feature -fma -target-feature -bmi -target-feature -avx2 -target-feature -avx512er -target-feature +sse -target-feature -lzcnt -target-feature -avx512f -target-feature +f16c -target-feature +mmx -target-feature +cmov -target-feature -xop -target-feature -rdseed -target-feature -movbe -target-feature -hle -target-feature -sha -target-feature +sse3 -target-feature -avx512dq -target-feature +aes -target-feature +pclmul -target-feature +rdrnd -target-feature +sse2 -target-feature +ssse3 -target-feature +sse4.1 -target-feature +sse4.2 -target-linker-version 253.3 -dwarf-column-info -ffunction-sections -fdata-sections -coverage-file /Users/ur20980/src/cryptopp/integer.cpp -resource-dir /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1 -stdlib=libc++ -O3 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/ur20980/src/cryptopp -ferror-limit 19 -fm
[llvm-bugs] [Bug 27840] New: Compilation triggers a compiler bug - it asked to report to llvm.org
https://llvm.org/bugs/show_bug.cgi?id=27840 Bug ID: 27840 Summary: Compilation triggers a compiler bug - it asked to report to llvm.org Product: clang Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: u...@ll.mit.edu CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Mac OS X 10.11.5, Xcode-7.3.1, Macports-2.3.4. The problem is with Macports-installed clang-3.7 (which was built using Xcode-7.3.1). Here's the screen log: clang++-mp-3.7 -maes -mpclmul -mrdrnd -msse2 -mssse3 -msse4.1 -msse4.2 -std=c++11 -ffunction-sections -fdata-sections -O3 -fPIC -march=native -pipe -c integer.cpp Assertion failed: (BB->getTerminator()->getNumSuccessors() == 1 && "Should have a single succ!"), function SplitEdge, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/llvm-3.7/work/llvm-3.7.1.src/lib/Transforms/Utils/BasicBlockUtils.cpp, line 262. 0 libLLVM-3.7.dylib0x00010ee3a6bf llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 57 1 libLLVM-3.7.dylib0x00010ee3ad0e SignalHandler(int) + 231 2 libsystem_platform.dylib 0x7fff92c6952a _sigtramp + 26 3 libsystem_platform.dylib 0x7fa9738024e8 _sigtramp + 3770257368 4 libsystem_c.dylib0x7fff8c8af6e7 abort + 129 5 libsystem_c.dylib0x7fff8c876df8 basename + 0 6 libLLVM-3.7.dylib0x00010eeb2d23 llvm::SplitBlock(llvm::BasicBlock*, llvm::Instruction*, llvm::DominatorTree*, llvm::LoopInfo*) + 0 7 libLLVM-3.7.dylib0x00010ebb253d (anonymous namespace)::JumpThreading::DuplicateCondBranchOnPHIIntoPred(llvm::BasicBlock*, llvm::SmallVectorImpl const&) + 981 8 libLLVM-3.7.dylib0x00010ebad752 (anonymous namespace)::JumpThreading::runOnFunction(llvm::Function&) + 4938 9 libLLVM-3.7.dylib0x00010e7258e5 llvm::FPPassManager::runOnFunction(llvm::Function&) + 297 10 libLLVM-3.7.dylib0x00010f09f74e (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 1230 11 libLLVM-3.7.dylib0x00010e725dc0 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 628 12 clang0x00010c911a6d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 6301 13 clang0x00010ca28d0c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 510 14 clang0x00010ca9ee7a clang::ParseAST(clang::Sema&, bool, bool) + 393 15 clang0x00010c7c63cf clang::FrontendAction::Execute() + 71 16 clang0x00010c79eebb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 553 17 clang0x00010c7726f6 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3822 18 clang0x00010c76adcd cc1_main(llvm::ArrayRef, char const*, void*) + 1389 19 clang0x00010c770e67 main + 8505 20 libdyld.dylib0x7fff90a385ad start + 1 21 libdyld.dylib0x0086 start + 1868331738 Stack dump: 0.Program arguments: /opt/local/libexec/llvm-3.7/bin/clang -cc1 -triple x86_64-apple-macosx10.11.0 -emit-obj -disable-free -main-file-name integer.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu ivybridge -target-feature -sse4a -target-feature -avx512bw -target-feature +cx16 -target-feature -tbm -target-feature -adx -target-feature -fma4 -target-feature -avx512vl -target-feature -prfchw -target-feature -bmi2 -target-feature -avx512pf -target-feature +fsgsbase -target-feature +avx -target-feature -avx512cd -target-feature -rtm -target-feature +popcnt -target-feature -fma -target-feature -bmi -target-feature -avx2 -target-feature -avx512er -target-feature +sse -target-feature -lzcnt -target-feature -avx512f -target-feature +f16c -target-feature +mmx -target-feature +cmov -target-feature -xop -target-feature -rdseed -target-feature -movbe -target-feature -hle -target-feature -sha -target-feature +sse3 -target-feature -avx512dq -target-feature +aes -target-feature +pclmul -target-feature +rdrnd -target-feature +sse2 -target-feature +ssse3 -target-feature +sse4.1 -target-feature +sse4.2 -target-linker-version 253.3 -dwarf-column-info -ffunction-sections -fdata-sections -coverage-file /Users/ur20980/src/cryptopp/integer.cpp -resource-dir /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1 -stdlib=libc++ -O3 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/ur20980/src/cryptopp -ferror-limit 19 -fm
[llvm-bugs] [Bug 27842] New: SafeStack disables stack coloring
https://llvm.org/bugs/show_bug.cgi?id=27842
Bug ID: 27842
Summary: SafeStack disables stack coloring
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Stack coloring is not being done on the unsafe stack.
$ cat 1.cc
void capture(int *);
#define X { int x; capture(&x); }
void f() { X X X X X X X X X X }
$ clang++ 1.cc -O3 -c -fsanitize=safe-stack && objdump -drl 1.o
<_Z1fv>:
_Z1fv():
0:55 push %rbp
1:41 57push %r15
3:41 56push %r14
5:41 55push %r13
7:41 54push %r12
9:53 push %rbx
a:48 83 ec 28 sub$0x28,%rsp
e:48 8b 0d 00 00 00 00 mov0x0(%rip),%rcx# 15
<_Z1fv+0x15>
11: R_X86_64_GOTTPOFF__safestack_unsafe_stack_ptr-0x4
15:64 4c 8b 39 mov%fs:(%rcx),%r15
19:49 8d 47 d0 lea-0x30(%r15),%rax
1d:64 48 89 01 mov%rax,%fs:(%rcx)
21:49 8d 7f fc lea-0x4(%r15),%rdi
25:49 8d 5f f8 lea-0x8(%r15),%rbx
29:4d 8d 67 f4 lea-0xc(%r15),%r12
2d:4d 8d 6f f0 lea-0x10(%r15),%r13
31:49 8d 6f ec lea-0x14(%r15),%rbp
35:4d 8d 77 e8 lea-0x18(%r15),%r14
39:49 8d 47 e4 lea-0x1c(%r15),%rax
3d:48 89 44 24 08 mov%rax,0x8(%rsp)
42:49 8d 47 e0 lea-0x20(%r15),%rax
46:48 89 44 24 10 mov%rax,0x10(%rsp)
4b:49 8d 47 dc lea-0x24(%r15),%rax
4f:48 89 44 24 18 mov%rax,0x18(%rsp)
54:49 8d 47 d8 lea-0x28(%r15),%rax
58:48 89 44 24 20 mov%rax,0x20(%rsp)
5d:e8 00 00 00 00 callq 62 <_Z1fv+0x62>
5e: R_X86_64_PC32_Z7capturePi-0x4
62:48 89 df mov%rbx,%rdi
65:e8 00 00 00 00 callq 6a <_Z1fv+0x6a>
66: R_X86_64_PC32_Z7capturePi-0x4
6a:4c 89 e7 mov%r12,%rdi
6d:e8 00 00 00 00 callq 72 <_Z1fv+0x72>
6e: R_X86_64_PC32_Z7capturePi-0x4
72:4c 89 ef mov%r13,%rdi
75:e8 00 00 00 00 callq 7a <_Z1fv+0x7a>
76: R_X86_64_PC32_Z7capturePi-0x4
7a:48 89 ef mov%rbp,%rdi
7d:e8 00 00 00 00 callq 82 <_Z1fv+0x82>
7e: R_X86_64_PC32_Z7capturePi-0x4
82:4c 89 f7 mov%r14,%rdi
85:e8 00 00 00 00 callq 8a <_Z1fv+0x8a>
86: R_X86_64_PC32_Z7capturePi-0x4
8a:48 8b 7c 24 08 mov0x8(%rsp),%rdi
8f:e8 00 00 00 00 callq 94 <_Z1fv+0x94>
90: R_X86_64_PC32_Z7capturePi-0x4
94:48 8b 7c 24 10 mov0x10(%rsp),%rdi
99:e8 00 00 00 00 callq 9e <_Z1fv+0x9e>
9a: R_X86_64_PC32_Z7capturePi-0x4
9e:48 8b 7c 24 18 mov0x18(%rsp),%rdi
a3:e8 00 00 00 00 callq a8 <_Z1fv+0xa8>
a4: R_X86_64_PC32_Z7capturePi-0x4
a8:48 8b 7c 24 20 mov0x20(%rsp),%rdi
ad:e8 00 00 00 00 callq b2 <_Z1fv+0xb2>
ae: R_X86_64_PC32_Z7capturePi-0x4
b2:48 8b 05 00 00 00 00 mov0x0(%rip),%rax# b9
<_Z1fv+0xb9>
b5: R_X86_64_GOTTPOFF__safestack_unsafe_stack_ptr-0x4
b9:64 4c 89 38 mov%r15,%fs:(%rax)
bd:48 83 c4 28 add$0x28,%rsp
c1:5b pop%rbx
c2:41 5cpop%r12
c4:41 5dpop%r13
c6:41 5epop%r14
c8:41 5fpop%r15
ca:5d pop%rbp
cb:c3 retq
This code has an unsafe stack frame of 0x30 bytes.
Without SafeStack it's just 8 bytes:
0:50 push %rax
1:48 8d 7c 24 04 lea0x4(%rsp),%rdi
6:e8 00 00 00 00 callq b <_Z1fv+0xb>
7: R_X86_64_PC32_Z7capturePi-0x4
...
--
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 27843] New: pragma pack struct + volatile results in an unresolved external "atomic_load" when using the Microsoft Linker
https://llvm.org/bugs/show_bug.cgi?id=27843
Bug ID: 27843
Summary: pragma pack struct + volatile results in an unresolved
external "atomic_load" when using the Microsoft Linker
Product: clang
Version: 3.8
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: llvmb...@endgame.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
A reference to a struct that uses "volatile" in combination with "#pragma
pack()" will yield optimized IR that uses atomic_load, which yields an
unresolved external when using the Microsoft linker. We were able to reproduce
this with Visual Studio 2010, 2012, and 2013 with the following sample program:
#pragma pack(push)
#pragma pack(1)
struct A {
volatile int f0;
};
#pragma pack(pop)
static const struct A g_A = { 0xFECDL };
int main (int argc, char* argv[])
{
int tmp = g_A.f0;
return 0;
}
When compiled with "/Od" so the relevant code doesn't get optimized out, here's
the IR with "volatile":
define i32 @main(i32 %argc, i8** %argv) #0 {
entry:
%retval = alloca i32, align 4
%argv.addr = alloca i8**, align 8
%argc.addr = alloca i32, align 4
%tmp = alloca i32, align 4
%atomic-temp = alloca i32, align 4
store i32 0, i32* %retval, align 4
store i8** %argv, i8*** %argv.addr, align 8
store i32 %argc, i32* %argc.addr, align 4
%0 = bitcast i32* %atomic-temp to i8*
call void @__atomic_load(i64 4, i8* bitcast (%struct.A* @g_A to i8*), i8* %0,
i32 2)
%atomic-load = load atomic volatile i32, i32* %atomic-temp acquire, align 4
store i32 %atomic-load, i32* %tmp, align 4
ret i32 0
}
And without "volatile":
define i32 @main(i32 %argc, i8** %argv) #0 {
entry:
%retval = alloca i32, align 4
%argv.addr = alloca i8**, align 8
%argc.addr = alloca i32, align 4
%tmp = alloca i32, align 4
store i32 0, i32* %retval, align 4
store i8** %argv, i8*** %argv.addr, align 8
store i32 %argc, i32* %argc.addr, align 4
%0 = load i32, i32* getelementptr inbounds (%struct.A, %struct.A* @g_A, i32
0, i32 0), align 1
store i32 %0, i32* %tmp, align 4
ret i32 0
}
If one removes the volatile keyword from the struct member, or removes the
pragma pack, the linking issue goes away. However, we believe the underlying
issue may be that the calling convention mentioned in
http://llvm.org/docs/Atomics.html#libcalls-atomic doesn't line up with how
Microsoft uses the atomic_load call, thus the linker can't resolve the correct
function.
Unsure if the fix should be to ensure the libcall to atomic_load isn't used, or
whether the convention should be fixed for builds on windows.
--
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 27844] New: SafeStack: unsafe alloca pointers are live throughout the function
https://llvm.org/bugs/show_bug.cgi?id=27844
Bug ID: 27844
Summary: SafeStack: unsafe alloca pointers are live throughout
the function
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In the following example, the address of each local variable is calculated in
advance and kept live in a register, and even spilled as necessary. It would be
enough to keep the base address of the unsafe stack frame (%r15 in this case)
in a register and calculate the addresses of variables when they are needed.
$ cat 1.cc
void capture(int *);
void f() {
int x0; capture(&x0);
int x1; capture(&x1);
int x2; capture(&x2);
int x3; capture(&x3);
int x4; capture(&x4);
int x5; capture(&x5);
int x6; capture(&x6);
int x7; capture(&x7);
int x8; capture(&x8);
int x9; capture(&x9);
}
$ clang++ 1.cc -O3 -c -fsanitize=safe-stack && objdump -drl 1.o
<_Z1fv>:
_Z1fv():
0:55 push %rbp
1:41 57push %r15
3:41 56push %r14
5:41 55push %r13
7:41 54push %r12
9:53 push %rbx
a:48 83 ec 28 sub$0x28,%rsp
e:48 8b 0d 00 00 00 00 mov0x0(%rip),%rcx# 15
<_Z1fv+0x15>
11: R_X86_64_GOTTPOFF__safestack_unsafe_stack_ptr-0x4
15:64 4c 8b 39 mov%fs:(%rcx),%r15
19:49 8d 47 d0 lea-0x30(%r15),%rax
1d:64 48 89 01 mov%rax,%fs:(%rcx)
21:49 8d 7f fc lea-0x4(%r15),%rdi
25:49 8d 5f f8 lea-0x8(%r15),%rbx
29:4d 8d 67 f4 lea-0xc(%r15),%r12
2d:4d 8d 6f f0 lea-0x10(%r15),%r13
31:49 8d 6f ec lea-0x14(%r15),%rbp
35:4d 8d 77 e8 lea-0x18(%r15),%r14
39:49 8d 47 e4 lea-0x1c(%r15),%rax
3d:48 89 44 24 08 mov%rax,0x8(%rsp)
42:49 8d 47 e0 lea-0x20(%r15),%rax
46:48 89 44 24 10 mov%rax,0x10(%rsp)
4b:49 8d 47 dc lea-0x24(%r15),%rax
4f:48 89 44 24 18 mov%rax,0x18(%rsp)
54:49 8d 47 d8 lea-0x28(%r15),%rax
58:48 89 44 24 20 mov%rax,0x20(%rsp)
5d:e8 00 00 00 00 callq 62 <_Z1fv+0x62>
5e: R_X86_64_PC32_Z7capturePi-0x4
62:48 89 df mov%rbx,%rdi
65:e8 00 00 00 00 callq 6a <_Z1fv+0x6a>
66: R_X86_64_PC32_Z7capturePi-0x4
6a:4c 89 e7 mov%r12,%rdi
6d:e8 00 00 00 00 callq 72 <_Z1fv+0x72>
6e: R_X86_64_PC32_Z7capturePi-0x4
72:4c 89 ef mov%r13,%rdi
75:e8 00 00 00 00 callq 7a <_Z1fv+0x7a>
76: R_X86_64_PC32_Z7capturePi-0x4
7a:48 89 ef mov%rbp,%rdi
7d:e8 00 00 00 00 callq 82 <_Z1fv+0x82>
7e: R_X86_64_PC32_Z7capturePi-0x4
82:4c 89 f7 mov%r14,%rdi
85:e8 00 00 00 00 callq 8a <_Z1fv+0x8a>
86: R_X86_64_PC32_Z7capturePi-0x4
8a:48 8b 7c 24 08 mov0x8(%rsp),%rdi
8f:e8 00 00 00 00 callq 94 <_Z1fv+0x94>
90: R_X86_64_PC32_Z7capturePi-0x4
94:48 8b 7c 24 10 mov0x10(%rsp),%rdi
99:e8 00 00 00 00 callq 9e <_Z1fv+0x9e>
9a: R_X86_64_PC32_Z7capturePi-0x4
9e:48 8b 7c 24 18 mov0x18(%rsp),%rdi
a3:e8 00 00 00 00 callq a8 <_Z1fv+0xa8>
a4: R_X86_64_PC32_Z7capturePi-0x4
a8:48 8b 7c 24 20 mov0x20(%rsp),%rdi
ad:e8 00 00 00 00 callq b2 <_Z1fv+0xb2>
ae: R_X86_64_PC32_Z7capturePi-0x4
b2:48 8b 05 00 00 00 00 mov0x0(%rip),%rax# b9
<_Z1fv+0xb9>
b5: R_X86_64_GOTTPOFF__safestack_unsafe_stack_ptr-0x4
b9:64 4c 89 38 mov%r15,%fs:(%rax)
bd:48 83 c4 28 add$0x28,%rsp
c1:5b pop%rbx
c2:41 5cpop%r12
c4:41 5dpop%r13
c6:41 5epop%r14
c8:41 5fpop%r15
ca:5d pop%rbp
cb:c3 retq
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailin
[llvm-bugs] [Bug 27845] New: Name lookup on inline variables does not account for live ranges on Windows
https://llvm.org/bugs/show_bug.cgi?id=27845
Bug ID: 27845
Summary: Name lookup on inline variables does not account for
live ranges on Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: ztur...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
If you have this code:
#include
void test1(int) __attribute__ ((always_inline));
void test2(int) __attribute__ ((always_inline));
void test2(int b) {
printf("test2(%d)\n", b);
}
void test1(int a) {
printf("test1(%d)\n", a);
test2(a+1);
}
int main() {
test2(42);
test1(23);
}
And you put a breakpoint in test2, it will get hit first with the value b=42,
and then again with the value b=24. If you're at the 2nd hit of the breakpoint
and you try to print the value of b, it says the name is ambiguous (presumably
because it can't decide between the first and the second b).
--
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 27846] New: Missed optimization: sink computation result to the first use
https://llvm.org/bugs/show_bug.cgi?id=27846
Bug ID: 27846
Summary: Missed optimization: sink computation result to the
first use
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In the code snippet below, clang -O3 produces different code for f() and g().
The code for f() computes all x0..x9 values early, resulting in lots of used
registers. If I add a bunch more calls (and x* variables), or switch to a
target with less registers, computation results will be spilled on stack.
void f() {
int *p = new int[10];
int *x0 = &p[0];
int *x1 = &p[1];
int *x2 = &p[2];
int *x3 = &p[3];
int *x4 = &p[4];
int *x5 = &p[5];
int *x6 = &p[6];
int *x7 = &p[7];
int *x8 = &p[8];
int *x9 = &p[9];
capture(x0);
capture(x1);
capture(x2);
capture(x3);
capture(x4);
capture(x5);
capture(x6);
capture(x7);
capture(x8);
capture(x9);
}
void g() {
int *p = new int[10];
int *x0 = &p[0];
capture(x0);
int *x1 = &p[1];
capture(x1);
int *x2 = &p[2];
capture(x2);
int *x3 = &p[3];
capture(x3);
int *x4 = &p[4];
capture(x4);
int *x5 = &p[5];
capture(x5);
int *x6 = &p[6];
capture(x6);
int *x7 = &p[7];
capture(x7);
int *x8 = &p[8];
capture(x8);
int *x9 = &p[9];
capture(x9);
}
<_Z1fv>:
_Z1fv():
0:f81a0ffb strx27, [sp,#-96]!
4:a90167fa stpx26, x25, [sp,#16]
8:a9025ff8 stpx24, x23, [sp,#32]
c:a90357f6 stpx22, x21, [sp,#48]
10:a9044ff4 stpx20, x19, [sp,#64]
14:a9057bfd stpx29, x30, [sp,#80]
18:910143fd addx29, sp, #0x50
1c:52800500 movw0, #0x28 // #40
20:9400 bl0 <_Znam>
24:91001013 addx19, x0, #0x4
28:91002014 addx20, x0, #0x8
2c:91003015 addx21, x0, #0xc
30:91004016 addx22, x0, #0x10
34:91005017 addx23, x0, #0x14
38:91006018 addx24, x0, #0x18
3c:91007019 addx25, x0, #0x1c
40:9100801a addx26, x0, #0x20
44:9100901b addx27, x0, #0x24
48:9400 bl0 <_Z7capturePi>
4c:aa1303e0 movx0, x19
50:9400 bl0 <_Z7capturePi>
...
00ac <_Z1gv>:
_Z1gv():
ac:f81e0ff3 strx19, [sp,#-32]!
b0:a9017bfd stpx29, x30, [sp,#16]
b4:910043fd addx29, sp, #0x10
b8:52800500 movw0, #0x28 // #40
bc:9400 bl0 <_Znam>
c0:aa0003f3 movx19, x0
c4:9400 bl0 <_Z7capturePi>
c8:91001260 addx0, x19, #0x4
cc:9400 bl0 <_Z7capturePi>
...
--
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 27847] New: Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"
https://llvm.org/bugs/show_bug.cgi?id=27847 Bug ID: 27847 Summary: Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!" Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16402 --> https://llvm.org/bugs/attachment.cgi?id=16402&action=edit preprocessed source for reproduction This assert started firing recently. Repro invocation: $ clang -cc1 -triple i686-pc-windows-msvc19.0.0 -emit-obj -target-cpu pentium4 -Os -fms-extensions -fms-compatibility -fms-compatibility-version=19.0 -fdelayed-template-parsing -x c /tmp/a.ii -- 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 27847] Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"
https://llvm.org/bugs/show_bug.cgi?id=27847 Michael Zolotukhin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Michael Zolotukhin --- Fixed in r270517. -- 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 27848] New: Incorrect optimization in memcpyopt with longjmp and volatile locals
https://llvm.org/bugs/show_bug.cgi?id=27848
Bug ID: 27848
Summary: Incorrect optimization in memcpyopt with longjmp and
volatile locals
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
#include
#include
#include
int zz = 1;
__attribute((noinline))
void g(volatile int* y, jmp_buf *b) {
*y = 10;
if (zz) longjmp(*b, 2);
}
__attribute((noinline))
int f() {
volatile int x, y;
x = 1;
jmp_buf b;
if (setjmp(b)) return x;
g(&y, &b);
memcpy((void*)&x, (void*)&y, 4);
return x;
}
int main() { if (f() != 1) abort(); }
Runs correctly with gcc or clang -O0; aborts with clang -O2. I'm pretty sure
it's a bug in memcpyopt: it's trying to do call slot optimization on y.
--
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 27849] New: Incorrect call slot optimization in memcpyopt with noalias
https://llvm.org/bugs/show_bug.cgi?id=27849
Bug ID: 27849
Summary: Incorrect call slot optimization in memcpyopt with
noalias
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
bool b = true;
__attribute((noinline))
void bar(int* x) { *x = 10; if (b) throw 0; }
__attribute((noinline))
void foo(int& __restrict x) {
int t;
bar(&t);
x = t;
}
int main() {
int x = 1;
try {
foo(x);
} catch (...) {}
if (x != 1) abort();
}
Works correctly with gcc and clang -O0; aborts with clang -O2.
Call slot optimization is being too aggressive in memcpyopt.
--
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 27850] New: Assertion failed: (AlreadyScheduled.insert(&GV).second && "Should not reschedule")
https://llvm.org/bugs/show_bug.cgi?id=27850 Bug ID: 27850 Summary: Assertion failed: (AlreadyScheduled.insert(&GV).second && "Should not reschedule") Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Linking the following module into an empty module (llvm-link empty.ll bug.ll) leads to an assertion: Assertion failed: (AlreadyScheduled.insert(&GV).second && "Should not reschedule"), function scheduleMapGlobalInitializer, file lib/Transforms/Utils/ValueMapper.cpp, line 1009. target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.9" @A = internal constant i8 1 @B = alias i8, i8* @A @C = global [2 x i8*] [i8* @A, i8* @B] It seems that the two maps (ValueMap and AliasValueMap) are not playing well with each other. We first visit @C, then materialize its initializer, which lead us to @A, which we schedule to be materialized later, and then move to B which also scheduled. At this point we moved with the worklist and process B first. Since it is an alias it will be materialized using the AliasValueMap, and we pull the aliasee @A and schedules it: this is where we hit the assertions because A was already scheduled. -- 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
