[llvm-bugs] [Bug 25245] clang takes a long time to compile an empty file including ExecutionEngine/Interpreter.h

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25245

Lang Hames  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Lang Hames  ---
Marking this resolved.

Davide - let me know if there's anything you want to follow up on and I can
re-open if necessary.

-- 
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 21040] Assertion failed in CGRecordLayoutBuilder.cpp:526 (Prior->Kind == MemberInfo::Field && !Prior->FD && "Only storage fields have tail padding!)

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=21040

David Majnemer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|C++ |LLVM Codegen
 Resolution|--- |FIXED

--- Comment #7 from David Majnemer  ---
Fixed in r251036.

-- 
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 25289] New: [AVX-512] LLC Turns "fpext" and "fpmul" into a wrong splitting and addition.

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25289

Bug ID: 25289
   Summary: [AVX-512] LLC Turns "fpext" and "fpmul" into a wrong
splitting and addition.
   Product: tools
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: llc
  Assignee: unassignedb...@nondot.org
  Reporter: shishpanov2...@yandex.ru
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15144
  --> https://llvm.org/bugs/attachment.cgi?id=15144=edit
The IR sample.

LLC tries to extend each of two parts of "%ptr_masked_load.16" in the attached
file. It takes the first half of this vector twice, but, I guess, it should
take two different halves of this vector. For example, the assembly code, what
is the result of LLC:

f_f:# @f_f
vmovups(%rsi), %zmm0
vcvtps2pd%ymm0, %zmm1
vextractf64x4$2, %zmm0, %ymm0
vcvtps2pd%ymm0, %zmm0
vaddpd%zmm0, %zmm0, %zmm2
vaddpd%zmm1, %zmm1, %zmm3
vmaxpd%zmm3, %zmm1, %zmm1
vmaxpd%zmm2, %zmm0, %zmm0
vcvtpd2ps%zmm1, %ymm1
vcvtpd2ps%zmm0, %ymm0
vinsertf64x4$1, %ymm0, %zmm1, %zmm0
vmovups%zmm0, (%rdi)
retq

I think, the "vextractf64x4" takes the wrong half of %zmm0.

key for LLC launch: -mcpu=knl

-- 
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 25288] New: bug with variadic class friend functions

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25288

Bug ID: 25288
   Summary: bug with variadic class friend functions
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: C++14
  Assignee: unassignedclangb...@nondot.org
  Reporter: ryan.b...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The below code compiles fine with gcc and EDG, but gives this error with clang:

rnburn@localhost ~/test/friend_auto $ c++14 t.cpp 
t.cpp:18:3: error: call to 'f' is ambiguous
  f(a);
  ^
t.cpp:6:15: note: candidate function [with Qx = ]
  friend auto f(A a);
  ^
t.cpp:12:6: note: candidate function [with Qx = ]
auto f(A a) {
 ^
1 error generated.

///
template   
class A {   
 public:
  A(int xx) : x(xx) {}  
  template 
  friend auto f(A a);
 private:   
  int x;
};  

template   
auto f(A a) {
  return a.x;   
}   

int main() {
  A a(22); 
  f(a); 
  return 0; 
}
///

-- 
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 25286] New: Profile Instrumentation and linker (gnu) garbage collection

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25286

Bug ID: 25286
   Summary: Profile Instrumentation and linker (gnu) garbage
collection
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: davi...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

If you use the latest clang to build an instrumented executable or shared
library with garbage collection turned on, you will get a linker error if the
linker is gnu ld:

clang -fprofile-instr-generate -fdata-sections -ffunction-sections
-Wl,--gc-sections t.c


The affected platform is Linux and FreeBSD. This is basically a gnu linker bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=19161


It is possible to workaround this by changing clang driver, but the solution is
hacky and temporary, so not desirable.

If you hit the problem, here are three solutions:

1) update the gnu linker (when the fix is released)
2) use gold linker: -fuse-ld=gold
3) use the following linker script -- name it prf_data.x


SECTIONS {
__llvm_prf_data : { KEEP(*(__llvm_prf_data)) }
}

and add the following link option: -Wl,-T,prf_data.x


Keep this bug open as a place holder to document the issue.

-- 
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 17519] Assertion `RegNo < NumRegs && "Attempting to access record for invalid register number!"' failed.

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=17519

Tim Besard  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||tim.bes...@elis.ugent.be
 Resolution|FIXED   |---

--- Comment #2 from Tim Besard  ---
Sorry to re-open, but I'm coming across this assertion as well, apparently not
fixed in r192444 for my case.

I'll be attaching some bitcode files for reproducing the issue; the 3.4 one
compatible with r192444, the others respectively for 3.7 and trunk.

$ llc reduced-trunk.ll
llc: llvm/src/llvm/include/llvm/MC/MCRegisterInfo.h:325: const
llvm::MCRegisterDesc ::MCRegisterInfo::operator[](unsigned int) const:
Assertion `RegNo < NumRegs && "Attempting to access record for invalid register
number!"' failed.
0  libLLVMSupport.so.3.8  0x7ffa1a225fde
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  libLLVMSupport.so.3.8  0x7ffa1a227179
2  libLLVMSupport.so.3.8  0x7ffa1a225b33 llvm::sys::RunSignalHandlers()
+ 131
3  libLLVMSupport.so.3.8  0x7ffa1a2275ff
4  libc.so.6  0x7ffa19302180
5  libc.so.6  0x7ffa19302107 gsignal + 55
6  libc.so.6  0x7ffa193034e8 abort + 328
7  libc.so.6  0x7ffa192fb226
8  libc.so.6  0x7ffa192fb2d2
9  libLLVMAsmPrinter.so.3.8   0x7ffa1cb8c557
10 libLLVMAsmPrinter.so.3.8   0x7ffa1cb8c4fb
11 libLLVMAsmPrinter.so.3.8   0x7ffa1cb79293
12 libLLVMAsmPrinter.so.3.8   0x7ffa1cb6d7c1
13 libLLVMAsmPrinter.so.3.8   0x7ffa1cb6c3c7
llvm::AsmPrinter::EmitFunctionBody() + 1143
14 libLLVMNVPTXCodeGen.so.3.8 0x7ffa1dd276e8
15 libLLVMNVPTXCodeGen.so.3.8 0x7ffa1dd19ebb
16 libLLVMCodeGen.so.3.8  0x7ffa1c48474e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
17 libLLVMCore.so.3.8 0x7ffa1bce97c0
llvm::FPPassManager::runOnFunction(llvm::Function&) + 416
18 libLLVMCore.so.3.8 0x7ffa1bce9af5
llvm::FPPassManager::runOnModule(llvm::Module&) + 117
19 libLLVMCore.so.3.8 0x7ffa1bcea2e1
20 libLLVMCore.so.3.8 0x7ffa1bce9ddb
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 347
21 libLLVMCore.so.3.8 0x7ffa1bcea821
llvm::legacy::PassManager::run(llvm::Module&) + 33
22 llc0x00414840
23 llc0x00413299 main + 233
24 libc.so.6  0x7ffa192eeb45 __libc_start_main + 245
25 llc0x00412f7d
Stack dump:
0.Program arguments: llc reduced-trunk.ll 
1.Running pass 'Function Pass Manager' on module 'reduced-trunk.ll'.
2.Running pass 'NVPTX Assembly Printer' on function '@kernel'
Aborted

-- 
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 25282] New: clang crass on enum class ParseAST when compiling in debug mode

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25282

Bug ID: 25282
   Summary: clang crass on enum class ParseAST when compiling in
debug mode
   Product: clang
   Version: 3.7
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: michael.kra...@jhuapl.edu
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15140
  --> https://llvm.org/bugs/attachment.cgi?id=15140=edit
clang diagnostic files I was asked to attach

Using the attached files and 
clang++ main.cpp -std=c++11 -g

I get a stack track from clang and a request to file a bug report

I've also tried -ggdb and -std=c++14. We specifically need this working on 14,
but it does break in 11 as well.

-- 
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 25291] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu (in 64-bit mode)

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25291

Bug ID: 25291
   Summary: clang crashes on valid code at -Os and above on
x86_64-linux-gnu (in 64-bit mode)
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The current clang trunk (as well as 3.6.x and 3.7.x) crashes when compiling the
following test case at -Os and above on x86_64-linux-gnu in the 64-bit mode
(but not in 32-bit mode). 

This is a regression from 3.5.x. 


$ clang-trunk -v
clang version 3.8.0 (trunk 250927)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$ 
$ clang-trunk -m32 -Os -c small.c
$ clang-trunk -m64 -O1 -c small.c
$ clang-3.5 -m64 -Os -c small.c
$ 
$ clang-trunk -m64 -Os -c small.c
clang: /tmp/llvm/lib/IR/Value.cpp:354: void
llvm::Value::replaceAllUsesWith(llvm::Value *): Assertion `!contains(New, this)
&& "this->replaceAllUsesWith(expr(this)) is NOT valid!"' failed.
#0 0x2e701dd llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/clang-trunk/bin/clang+0x2e701dd)
#1 0x2e6f866 llvm::sys::RunSignalHandlers()
(/usr/local/clang-trunk/bin/clang+0x2e6f866)
#2 0x2e719fe (/usr/local/clang-trunk/bin/clang+0x2e719fe)
#3 0x7fb0332c9340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#4 0x7fb032264cc9 gsignal
/build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7fb0322680d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7fb03225db86 __assert_fail_base
/build/buildd/eglibc-2.19/assert/assert.c:92:0
#7 0x7fb03225dc32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32)
#8 0x2decc01 llvm::Value::replaceAllUsesWith(llvm::Value*)
(/usr/local/clang-trunk/bin/clang+0x2decc01)
#9 0x275c3e9 (/usr/local/clang-trunk/bin/clang+0x275c3e9)
#10 0x2759d95 (/usr/local/clang-trunk/bin/clang+0x2759d95)
#11 0x2dbf5f4 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/clang-trunk/bin/clang+0x2dbf5f4)
#12 0x2a68688 (/usr/local/clang-trunk/bin/clang+0x2a68688)
#13 0x2dbfd15 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/clang-trunk/bin/clang+0x2dbfd15)
#14 0x9ecaf3 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang+0x9ecaf3)
#15 0x9cf0c3 (/usr/local/clang-trunk/bin/clang+0x9cf0c3)
#16 0xc5fb66 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang+0xc5fb66)
#17 0x77e695 clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang+0x77e695)
#18 0x74b10b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang+0x74b10b)
#19 0x72a82e clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang+0x72a82e)
#20 0x7208d3 cc1_main(llvm::ArrayRef, char const*, void*)
(/usr/local/clang-trunk/bin/clang+0x7208d3)
#21 0x728e23 main (/usr/local/clang-trunk/bin/clang+0x728e23)
#22 0x7fb03224fec5 __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:321:0
#23 0x720369 _start (/usr/local/clang-trunk/bin/clang+0x720369)
Stack dump:
0.Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.24 -momit-leaf-frame-pointer -dwarf-column-info

[llvm-bugs] [Bug 25292] New: Missing warning for unused variables in catch statement

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25292

Bug ID: 25292
   Summary: Missing warning for unused variables in catch
statement
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: vexoc...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15145
  --> https://llvm.org/bugs/attachment.cgi?id=15145=edit
Test case

In the snippet below I expected an unused variable warning for "foo", though no
such warning was emitted.

int main()
{
try
{
}
catch (int const )
{
}
}

-- 
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 25280] Long compile times, high memory usage for function containing large number of inlined functions

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25280

Matthias Braun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
   Assignee|unassignedclangbugs@nondot. |ma...@braunis.de
   |org |

--- Comment #2 from Matthias Braun  ---
On llvm trunk r251064 "opt -O3" requires 30 seconds for optimisation, 22
seconds for two runs of Value Propagation, which isn't great but still good for
a file this size.

The codegen part (llc -O3) requires around 8 seconds for either the optimized
or nonoptimized .ll file (top being "Eliminate PHI nodes for register
allocation" with 5 seconds) for the unoptimized file. Having PHI elimination on
the top is again strange, but 8 seconds for codegeneration is fine.

So it seems this no longer reproduces with llvm ToT. Maybe upgrading to llvm
3.7 will already be enough for you.

I'm closing this bugreport, technically the bug is still present in 3.6 but I
don't think it is worth fixing it when llvm ToT doesn't reproduce.

opt-top:
   ---User Time---   --System Time--   --User+System--   ---Wall Time---  ---
Name ---
  11.9388 ( 42.4%)   0.7151 ( 35.9%)  12.6539 ( 41.9%)  12.6571 ( 41.9%)  Value
Propagation
  11.4563 ( 40.6%)   0.7037 ( 35.4%)  12.1600 ( 40.3%)  12.1624 ( 40.3%)  Value
Propagation
   1.3507 (  4.8%)   0.0091 (  0.5%)   1.3598 (  4.5%)   1.3600 (  4.5%) 
Global Value Numbering
   0.5758 (  2.0%)   0.0107 (  0.5%)   0.5866 (  1.9%)   0.5865 (  1.9%) 
Function Integration/Inlining
   0.1924 (  0.7%)   0.1918 (  9.6%)   0.3841 (  1.3%)   0.3841 (  1.3%)  Lazy
Value Information Analysis
   0.1918 (  0.7%)   0.1914 (  9.6%)   0.3832 (  1.3%)   0.3833 (  1.3%)  Lazy
Value Information Analysis
   0.2077 (  0.7%)   0.0041 (  0.2%)   0.2119 (  0.7%)   0.2119 (  0.7%) 
Combine redundant instructions
   0.1389 (  0.5%)   0.0030 (  0.2%)   0.1418 (  0.5%)   0.1418 (  0.5%) 
Combine redundant instructions
   0.1340 (  0.5%)   0.0013 (  0.1%)   0.1353 (  0.4%)   0.1353 (  0.4%) 
Combine redundant instructions
   0.1139 (  0.4%)   0.0032 (  0.2%)   0.1171 (  0.4%)   0.1170 (  0.4%) 
Combine redundant instructions
   0.1109 (  0.4%)   0.0026 (  0.1%)   0.1135 (  0.4%)   0.1134 (  0.4%) 
Combine redundant instructions
   0.1025 (  0.4%)   0.0026 (  0.1%)   0.1051 (  0.3%)   0.1050 (  0.3%) 
Combine redundant instructions
   0.0759 (  0.3%)   0.0139 (  0.7%)   0.0898 (  0.3%)   0.0903 (  0.3%)  Print
module to stderr
   0.0855 (  0.3%)   0.0002 (  0.0%)   0.0857 (  0.3%)   0.0857 (  0.3%) 
Induction Variable Simplification
   0.0829 (  0.3%)   0.0018 (  0.1%)   0.0847 (  0.3%)   0.0847 (  0.3%) 
Combine redundant instru

llc-top:
   5.0728 ( 59.5%)   0.0057 (  2.6%)   5.0784 ( 58.1%)   5.0816 ( 57.9%) 
Eliminate PHI nodes for register allocation
   1.2483 ( 14.7%)   0.1065 ( 48.7%)   1.3548 ( 15.5%)   1.3741 ( 15.7%)  X86
DAG->DAG Instruction Selection
   0.3867 (  4.5%)   0.0120 (  5.5%)   0.3987 (  4.6%)   0.3988 (  4.5%)  Merge
disjoint stack slots
   0.2768 (  3.2%)   0.0116 (  5.3%)   0.2884 (  3.3%)   0.2887 (  3.3%) 
Greedy Register Allocator
   0.2743 (  3.2%)   0.0022 (  1.0%)   0.2765 (  3.2%)   0.2769 (  3.2%) 
Simple Register Coalescing
   0.1547 (  1.8%)   0.0009 (  0.4%)   0.1556 (  1.8%)   0.1566 (  1.8%) 
Machine Instruction Scheduler
   0.0932 (  1.1%)   0.0104 (  4.7%)   0.1036 (  1.2%)   0.1036 (  1.2%)  Live
Interval Analysis
   0.0780 (  0.9%)   0.0099 (  4.6%)   0.0880 (  1.0%)   0.0947 (  1.1%)  X86
Assembly / Object Emitter
   0.0873 (  1.0%)   0.0036 (  1.7%)   0.0910 (  1.0%)   0.0909 (  1.0%)  Live
Variable Analysis
   0.0608 (  0.7%)   0.0003 (  0.1%)   0.0611 (  0.7%)   0.0611 (  0.7%) 
Control Flow Optimizer
   0.0503 (  0.6%)   0.0010 (  0.5%)   0.0513 (  0.6%)   0.0513 (  0.6%) 
Machine Common Subexpression Elimination
   0.0454 (  0.5%)   0.0006 (  0.3%)   0.0460 (  0.5%)   0.0477 (  0.5%) 
CodeGen Prepare
   0.0454 (  0.5%)   0.0014 (  0.6%)   0.0468 (  0.5%)   0.0468 (  0.5%) 
Virtual Register Rewriter
   0.0386 (  0.5%)   0.0006 (  0.3%)   0.0392 (  0.4%)   0.0391 (  0.4%) 
Prologue/Epilogue Insertion & Frame Finalization
   0.0357 (  0.4%)   0.0006 (  0.3%)   0.0363 (  0.4%)   0.0363 (  0.4%) 
Module Verifier
   0.0337 (  0.4%)   0.0006 (  0.3%)   0.0343 (  0.4%)   0.0343 (  0.4%) 
Module Verifier

-- 
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 25293] New: Overlapping memcpy in SmallVector.h (via SmallString::operator=())

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25293

Bug ID: 25293
   Summary: Overlapping memcpy in SmallVector.h (via
SmallString::operator=())
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Support Libraries
  Assignee: unassignedb...@nondot.org
  Reporter: matti...@yahoo.co.uk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

clang version 3.8.0 (http://llvm.org/git/clang.git
3a551363c4cdd54c939cd9cc969d45bc8f8e93d8) (http://llvm.org/git/llvm.git
ca4c86d2fd31ba4c23b9f3028e4f812713f230c6)
Target: x86_64-unknown-linux-gnu
Thread model: posix

==26255== Memcheck, a memory error detector
==26255== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26255== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==26255== Command: clang++ --std=c++14 -I/usr/local/include -E -o
/tmp/56294cc2_0xffefffa30/testcase.ii /tmp/56294cc2_0xffefffa30/testcase.cpp
==26255== 
==26255== Source and destination overlap in memcpy(0xffeffe7c0, 0xffeffe7c0,
42)
==26255==at 0x6D140CD: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
==26255==by 0x9E5724:
_ZN4llvm23SmallVectorTemplateBaseIcLb1EE18uninitialized_copyIKccEEvPT_S5_PT0_PNSt9enable_ifIXsr3std7is_sameINSt12remove_constIS4_E4typeES6_EE5valueEvE4typeE
(SmallVector.h:328)
==26255==by 0x9E55AA: void llvm::SmallVectorImpl::append(char const*, char const*) (SmallVector.h:430)
==26255==by 0x9E586F: void llvm::SmallString<128u>::append(char const*, char const*) (SmallString.h:75)
==26255==by 0x9E5824: llvm::SmallString<128u>::operator+=(llvm::StringRef)
(SmallString.h:286)
==26255==by 0x9E5247: llvm::SmallString<128u>::operator=(llvm::StringRef)
(in /.../build-debug/bin/clang-3.8)
==26255==by 0x9DE90D: SetInstallDir(llvm::SmallVectorImpl&,
clang::driver::Driver&, bool) (driver.cpp:293)
==26255==by 0x9DD74A: main (driver.cpp:435)


Suggested change:

diff --git a/include/llvm/ADT/SmallVector.h b/include/llvm/ADT/SmallVector.h
index d1062ac..d6f13f3 100644
--- a/include/llvm/ADT/SmallVector.h
+++ b/include/llvm/ADT/SmallVector.h
@@ -324,7 +324,7 @@ protected:
 // iterators): std::uninitialized_copy optimizes to memmove, but we can
 // use memcpy here. Note that I and E are iterators and thus might be
 // invalid for memcpy if they are equal.
-if (I != E)
+if (I != E && I != Dest)
   memcpy(Dest, I, (E - I) * sizeof(T));
   }


Looking further, I guess it's ok for SmallString to clear() the underlying
SmallVector in the assignment operator. Even though the "StringRef RHS"
returned by parent_path still points into the data being cleared, it's not
going to go anywhere as a parent path is always going to be shorter. Either
way, the overlapping memcpy could be avoided as above.


driver.cpp:293

  InstalledPath = llvm::sys::path::parent_path(InstalledPath);



SmallString.h:280-288

  const SmallString =(StringRef RHS) {
this->clear();
return *this += RHS;
  }

  SmallString +=(StringRef RHS) {
this->append(RHS.begin(), RHS.end());
return *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 25281] New: opt -basicaa -scev-aa -loop-vectorize -print-alias-sets -S crash

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25281

Bug ID: 25281
   Summary: opt  -basicaa -scev-aa -loop-vectorize
-print-alias-sets -S  crash
   Product: new-bugs
   Version: 3.7
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: bique.alexan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15136
  --> https://llvm.org/bugs/attachment.cgi?id=15136=edit
x.ll

opt -basicaa -scev-aa -loop-vectorize -print-alias-sets -S x.ll
#0 0x7f7bc1b44228 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/bin/../lib/libLLVM.so.3.7+0x562228)
#1 0x7f7bc1b43041 (/usr/bin/../lib/libLLVM.so.3.7+0x561041)
#2 0x7f7bc0eef680 __restore_rt (/usr/bin/../lib/libc.so.6+0x33680)
#3 0x7f7bc1c6545d
llvm::PMTopLevelManager::setLastUser(llvm::ArrayRef, llvm::Pass*)
(/usr/bin/../lib/libLLVM.so.3.7+0x68345d)
#4 0x7f7bc1c6683a llvm::PMDataManager::add(llvm::Pass*, bool)
(/usr/bin/../lib/libLLVM.so.3.7+0x68483a)
#5 0x7f7bc1c68278 llvm::PMTopLevelManager::schedulePass(llvm::Pass*)
(/usr/bin/../lib/libLLVM.so.3.7+0x686278)
#6 0x419942 main (/usr/bin/opt+0x419942)
#7 0x7f7bc0edc610 __libc_start_main (/usr/bin/../lib/libc.so.6+0x20610)
#8 0x41a729 _start (/usr/bin/opt+0x41a729)
Stack dump:
0.Program arguments: opt -basicaa -scev-aa -loop-vectorize
-print-alias-sets -S x.ll 
Segmentation fault (core dumped)

-- 
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 25285] New: GVN removes assumes if there are multiple assumes for the same predicate in a loop

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25285

Bug ID: 25285
   Summary: GVN removes assumes if there are multiple assumes for
the same predicate in a loop
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: michael.m.kuperst...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Running GVN over the below test case results in both assumes being removed:

define i32 @foo (i32 %val, i1 %k) {
  br label %next

next:
  tail call void @llvm.assume(i1 %k)
  tail call void @llvm.assume(i1 %k)
  %ret = call i32 @do(i32 %val)
  %cont = call i1 @continue(i32 %ret)
  br i1 %cont, label %next, label %end

end:
  ret i32 %ret
}

declare i1 @continue(i32) #0
declare i32 @do(i32) #0
declare void @llvm.assume(i1) #0

attributes #0 = { nounwind }

This does not happen if there is only one assume in the "next" block, or if the
block is not in a loop (e.g. the branch is an unconditional branch to "end")

-- 
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 25283] New: Executable crashes when linked with lld & -O2

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25283

Bug ID: 25283
   Summary: Executable crashes when linked with lld & -O2
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: ism...@i10z.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15141
  --> https://llvm.org/bugs/attachment.cgi?id=15141=edit
Testcase

This is on Linux x86_64:

λ clang -v
clang version 3.8.0 (trunk 250995)
Target: x86_64-suse-linux
Thread model: posix
InstalledDir: /opt/clang/bin
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/5
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/5
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64


λ clang++ -x c++ -O2 -std=c++11 -fuse-ld=lld2 mandelbrot-mp.ii
λ ./a.out
[1]30266 segmentation fault (core dumped)  ./a.out

Works fine if I use -O1 or gold linker. Testcase attached.

-- 
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 24686] PowerPC unimplemented relocation assertion

2015-10-22 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=24686

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Bill Schmidt  ---
Fixed with r251027.

-- 
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