[llvm-bugs] [Bug 28516] New: LangRef: call's fnty no longer is a pointer type

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28516

Bug ID: 28516
   Summary: LangRef: call's fnty no longer is a pointer type
   Product: Documentation
   Version: 3.7
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: General docs
  Assignee: unassignedb...@nondot.org
  Reporter: j-llvmbugtrac...@watlock.be
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I'm not sure whether this is a documentation or an llvm IR parser bug.

In llvm 3.5, the "fnty" of a call instruction in LLVM IR (if specified) is a
function pointer type and must end in a "*".

In llvm 3.7, the "fnty" of a call instruction in LLVM IR (if specified) appears
to be a plain "function" type and must not end in a "*".

Example:

Accepted by LLVM 3.5:
  %5 = call i32 (i32)* @test(i32 %4)

Accepted by LLVM 3.7:
  %5 = call i32 (i32) @test(i32 %4)

The documentation both for LLVM 3.5 and 3.7 says the "fnty*" syntax is the
correct one. I don't know with which LLVM version exactly this changed.

-- 
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 28517] New: Unable to call a protected member function from a derived class

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28517

Bug ID: 28517
   Summary: Unable to call a protected member function from a
derived class
   Product: clang
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++14
  Assignee: unassignedclangb...@nondot.org
  Reporter: roman.perepeli...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

struct B1 {
   protected:
static void F(int);
  };

  struct B2 : B1 {
   protected:
using B1::F;
static void F();
  };

  struct D : B2 {
template 
using Void = decltype(D::F(T()));
  };

  void Test() {
using Void = D::Void;
  }

Expected behaviour: compiles.
Actual behaviour: compile error (see below).

  15 : error: 'F' is a protected member of 'B2'
  using Void = decltype(D::F(T()));
  ~~~^
  19 : note: in instantiation of template type alias 'Void' requested here
  using Void = D::Void;
  ^
  9 : note: declared protected here
  using B1::F;
  ^

-- 
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 28518] New: fatal error: error in backend: Cannot select: intrinsic %llvm.x86.bmi.pdep.32

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28518

Bug ID: 28518
   Summary: fatal error: error in backend: Cannot select:
intrinsic %llvm.x86.bmi.pdep.32
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: jo...@dyalog.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16726
  --> https://llvm.org/bugs/attachment.cgi?id=16726&action=edit
.cpp and .sh files generated at the time of failure.

Had the error compiling with make probably running 4 instances of clang
concurrently. Full output from the compiler as follows:

fatal error: error in backend: Cannot select: intrinsic %llvm.x86.bmi.pdep.32
clang.exe: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 3.8.243773
Target: i386-unknown-linux
Thread model: posix
clang.exe: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang.exe: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang.exe: note: diagnostic msg: C:\tmp\bmi2-501063.cpp
clang.exe: note: diagnostic msg: C:\tmp\bmi2-501063.sh
clang.exe: note: diagnostic msg:

The .cpp and .sh files are in the attached zip.

-- 
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 13958] LLVM doesn't optimize 64-bit inequalities best

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=13958

John Brawn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||john.brawn@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from John Brawn  ---
This was fixed in r268557. With latest trunk if I compile

int fn(long long a, int *p)
{
  if (a < 0) {
*p = 1;
return 2;
  } else if (a > 0) { 
*p = 2;
return 3;
  } else { 
*p = 3;
return 4;
  }
}

then InstCombine turns the a > 0 into a != 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 28311] Regression(r273807): Assertion failed: UndefinedSubrange || ElementSize == Size when building chrome/win with debug info

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28311

Amjad Aboud  changed:

   What|Removed |Added

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

--- Comment #3 from Amjad Aboud  ---
Resolved in rL275167.
Handled array where element type is typedef, volatile or constant.

-- 
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 28519] New: __make_integer_seq type crashes clang in mangling template function

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28519

Bug ID: 28519
   Summary: __make_integer_seq type crashes clang in mangling
template function
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: akotul...@fb.com
CC: david.majne...@gmail.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16727
  --> https://llvm.org/bugs/attachment.cgi?id=16727&action=edit
stack trace

Calling a function that adds __make_integer_seq<...> to its mangled name causes
a crash inside mangling code. I tested on clang trunk from July 8th (last rev
is r274885). r275047 fixes another problem with __make_integer_seq but it most
likely doesn't fix mangling crash.

Stack trace in attachment.

Code:

// compile in c++14 mode
#include   

template 
__make_integer_seq make(){}  

int main() {
  make<5>();
}

-- 
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 28520] New: type_tag_for_datatype causes clang to crash in some cases.

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28520

Bug ID: 28520
   Summary: type_tag_for_datatype causes clang to crash in some
cases.
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: pierregoussea...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Use of type_tag_for_datatype causes clang to crash in some cases.

clang 3.9 trunk@r275160
Target: x86_64-unknown-linux-gnu


static const int test_void
  __attribute__((type_tag_for_datatype
 (test, void))) = 0;
#define TEST_VOID 0

void test(int datatype, ...)
  __attribute__((argument_with_type_tag(test,2,1)));

int main() {
  test(TEST_VOID);
  return 0;
}


clang -c test.c
#0 0x0129a165 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
#1 0x012980ce llvm::sys::RunSignalHandlers()
#2 0x01298232 SignalHandler(int)
#3 0x7fb061f86340 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#4 0x01f4caba
clang::Sema::CheckArgumentWithTypeTag(clang::ArgumentWithTypeTagAttr const*,
clang::Expr const* const*)
...
Stack dump:
0.  Program arguments: clang-3.9 -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name tag.c -mrelocation-model
static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-dwarf-column-info -debugger-tuning=gdb -coverage-file lab/tag.c -resource-dir
llvm/install/bin/../lib/clang/3.9.0 -internal-isystem /usr/local/include
-internal-isystem llvm/install/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir lab -ferror-limit 19 -fmessage-length 168
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o tag.o -x c
tag.c
1.  tag.c:10:17: current parser token ')'
2.  tag.c:9:12: parsing function body 'main'
3.  tag.c:9:12: in compound statement ('{}')

-- 
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 28521] New: LLVM bug or sth else?

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28521

Bug ID: 28521
   Summary: LLVM bug or sth else?
   Product: libraries
   Version: 3.8
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: ARM
  Assignee: unassignedb...@nondot.org
  Reporter: tulip...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16728
  --> https://llvm.org/bugs/attachment.cgi?id=16728&action=edit
Function dump and full assembly files

I've got a problem with a piece of LLVM generated code (from Rust) that crashes
with a SIGILL on my ARM Linux system (it's about memory and not unsupported
instructions) and I'm not sure if it's reasonable to blame llvm codegen.

The crashing code comes from using the `-Z orbit` option and it runs fine when
compiled without.
It gets interesting because the crash doesn't reproduce under valgrind or qemu.

I'm attaching assembly dumps of the function from the crashing/working
versions, the main difference in short:

str r0, [r0, r8]! 

vs

str r1, [r0, r8]!

Any ideas welcome, thanks!

-- 
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 28521] LLVM bug or something else?

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28521

James Molloy  changed:

   What|Removed |Added

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

--- Comment #1 from James Molloy  ---
Hi Pete,

I'm afraid we can't do anything with this bug as-is. Firstly I have no idea
what "-Z orbit" is or does; it's not related to LLVM. Secondly there are no
input files to replicate the problem.

Before a bugzilla ticket is raised, it's ideal to have an idea of why it's LLVM
at fault. A testcase, reduced as much as possible, is absolutely required
before we can take any action, along with an explanation of the buggy behaviour
it shows. From that we can reproduce and start to investigate if it is LLVM at
fault.

The testcase should be in LLVM IR ideally.

Cheers,

James

-- 
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 28522] New: libclc build error with current llvm/clang

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28522

Bug ID: 28522
   Summary: libclc build error with current llvm/clang
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: adf.li...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Not sure where to file this or when it started (I haven't rebuilt libclc for
some time).

Trying to build current git libclc against git llvm, clang gives -

andy [libclc]$ ./configure.py --prefix=/usr
andy [libclc]$ make
LLVM-AS generic--/lib/subnormal_disable.bc
LLVM-AS generic--/lib/subnormal_use_default.bc
LLVM-CC nvptx--nvidiacl/lib/synchronization/barrier.cl.bc
./ptx-nvidiacl/lib/synchronization/barrier.cl:5:5: error: use of unknown
builtin '__builtin_ptx_bar_sync' [-Wimplicit-function-declaration]
__builtin_ptx_bar_sync(0);
^
1 error generated.
Makefile:29: recipe for target
'nvptx--nvidiacl/lib/synchronization/barrier.cl.bc' failed
make: *** [nvptx--nvidiacl/lib/synchronization/barrier.cl.bc] Error 1

-- 
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 28523] New: Unexpected compilation error with OpenMP: reference to local variable declared in enclosing function

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28523

Bug ID: 28523
   Summary: Unexpected compilation error with OpenMP: reference to
local variable declared in enclosing function
   Product: OpenMP
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Clang Compiler Support
  Assignee: unassignedclangb...@nondot.org
  Reporter: ti...@skewed.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16730
  --> https://llvm.org/bugs/attachment.cgi?id=16730&action=edit
Test program that causes the error.

The attached test fails with:


$ clang++ --std=gnu++14 -fopenmp clang_test.cc -o clang_test
clang_test.cc:20:23: error: reference to local variable 'x' declared in
enclosing function 'main'
  x = y;
  ^
clang_test.cc:9:9: note: in instantiation of function template specialization
'main()::(anonymous class)::operator()' requested here
f(v[i]);
^
clang_test.cc:16:5: note: in instantiation of function template specialization
'parallel_loop >, (lambda at
clang_test.cc:17:19)>' requested here
parallel_loop(v,
^
clang_test.cc:15:12: note: 'x' declared here
double x;
   ^
1 error generated.


GCC compiles this fine, and I don't see why clang shouldn't 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 28524] New: Assertion failed: (Bits != 0 && "Cannot print this instruction.") for patchable functions

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28524

Bug ID: 28524
   Summary: Assertion failed: (Bits != 0 && "Cannot print this
instruction.") for patchable functions
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: i...@azulsystems.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16731
  --> https://llvm.org/bugs/attachment.cgi?id=16731&action=edit
test case

$ llvm/buildDA/bin/llc -O3 test.ll
Assertion failed: (Bits != 0 && "Cannot print this instruction."), function
printInstruction, file llvm/buildDA/lib/Target/X86/X86GenAsmWriter.inc, line
46606.
Stack dump:
0.Program arguments: llvm/buildDA/bin/llc -O3 tmp.ll
1.Running pass 'Function Pass Manager' on module 'tmp.ll'.
2.Running pass 'X86 Assembly / Object Emitter' on function '@test'


Problem happens when we are trying to print "PATCHABLE_OP 2, KILL, "
"X86AsmPrinter::LowerPATCHABLE_OP" can't handle target independent opcodes.

Problematic instruction is generated from PatchableFunction.cpp. It looks for
the first instruction which in this case turns out to be KILL. I suspect that
http://reviews.llvm.org/rL274952 is indirectly responsible for such behaviour.

-- 
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 28519] __make_integer_seq type crashes clang in mangling template function

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28519

David Majnemer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Majnemer  ---
Fixed in r275190.

-- 
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 28525] New: %T is not defined correctly in LIT docs

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28525

Bug ID: 28525
   Summary: %T is not defined correctly in LIT docs
   Product: Documentation
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: General docs
  Assignee: unassignedb...@nondot.org
  Reporter: oribr...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The doc in http://llvm.org/docs/TestingGuide.html says:

%T - Directory of %t.

The doc in http://llvm.org/docs/CommandGuide/lit.html says:

%T - temporary directory unique to the test

These two definitions are not identical, and when working with lit, I noticed
that the first definition is the correct one. This can cause a problem when one
runs llvm-lit multithreaded on tests for which %S is the same (therefore %T
will also be the same, contradicting the uniqueness in the second definition).

-- 
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 25263] LiveIn lists for MBBs are incorrect

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25263

Matthias Braun  changed:

   What|Removed |Added

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

--- Comment #3 from Matthias Braun  ---
Marking this as fixed now that http://reviews.llvm.org/D22027 has landed in
r275201.

I believe it to be fixed even though I cannot reproduce with the original
testcase. Please verify and 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 28492] SCCP fails to fold constant structs

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28492

Davide Italiano  changed:

   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 28526] New: Compilation fails with error on PPC Ubuntu 15.10

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28526

Bug ID: 28526
   Summary: Compilation fails with error on PPC Ubuntu 15.10
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: mlpes...@us.ibm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16733
  --> https://llvm.org/bugs/attachment.cgi?id=16733&action=edit
Preprocessed source

/home/ubuntu/llvm/build/dev.git/bin/clang -Isrc/include -std=gnu99 -g -Wall
-fPIC -O3 -fno-common -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_REENTRANT
-D_GNU_SOURCE -DMEM_COUNT -DENHANCED_ALLOC -finline-functions -rdynamic
-I/home/ubuntu/aerospike-server-llvm/cf/include -o
target/Linux-ppc64le/obj/common/aerospike/as_module.o -c
src/main/aerospike/as_module.c
clang-3.9: warning: argument unused during compilation: '-rdynamic'
clang-3.9:
/home/ubuntu/llvm/src/dev.git/lib/Target/PowerPC/PPCFrameLowering.cpp:1155:
virtual void llvm::PPCFrameLowering::emitEpilogue(llvm::MachineFunction&,
llvm::MachineBasicBlock&) const: Assertion `SingleScratchReg && "Could not find
an available scratch register"' failed.
#0 0x1393aa60 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/ubuntu/llvm/src/dev.git/lib/Support/Unix/Signals.inc:402:0
#1 0x1393aed8 PrintStackTraceSignalHandler(void*)
/home/ubuntu/llvm/src/dev.git/lib/Support/Unix/Signals.inc:469:0
#2 0x13938650 llvm::sys::RunSignalHandlers()
/home/ubuntu/llvm/src/dev.git/lib/Support/Signals.cpp:45:0
#3 0x13939e44 SignalHandler(int)
/home/ubuntu/llvm/src/dev.git/lib/Support/Unix/Signals.inc:246:0
#4 0x3fffb3230478  0x478 gsignal
#5 0x3fffb3230478 
#6 0x3fffb3230478 abort (+0x478)
#7 0x3fffb2c3f094 (/lib/powerpc64le-linux-gnu/libc.so.6+0x3f094)
#8 0x3fffb2c4199c __assert_fail
(/lib/powerpc64le-linux-gnu/libc.so.6+0x4199c)
#9 0x3fffb2c349e4
llvm::PPCFrameLowering::emitEpilogue(llvm::MachineFunction&,
llvm::MachineBasicBlock&) const
/home/ubuntu/llvm/src/dev.git/lib/Target/PowerPC/PPCFrameLowering.cpp:1154:0
#10 0x3fffb2c34ad4 (anonymous
namespace)::PEI::insertPrologEpilogCode(llvm::MachineFunction&)
/home/ubuntu/llvm/src/dev.git/lib/CodeGen/PrologEpilogInserter.cpp:978:0
#11 0x122469dc (anonymous
namespace)::PEI::runOnMachineFunction(llvm::MachineFunction&)
/home/ubuntu/llvm/src/dev.git/lib/CodeGen/PrologEpilogInserter.cpp:211:0
#12 0x12cad18c
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/home/ubuntu/llvm/src/dev.git/lib/CodeGen/MachineFunctionPass.cpp:60:0
#13 0x12ca9258 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/ubuntu/llvm/src/dev.git/lib/IR/LegacyPassManager.cpp:1526:0
#14 0x12bbcfd0 llvm::FPPassManager::runOnModule(llvm::Module&)
/home/ubuntu/llvm/src/dev.git/lib/IR/LegacyPassManager.cpp:1547:0
#15 0x1313c250 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/ubuntu/llvm/src/dev.git/lib/IR/LegacyPassManager.cpp:1603:0
#16 0x1313c4a0 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/ubuntu/llvm/src/dev.git/lib/IR/LegacyPassManager.cpp:1706:0
#17 0x1313ca00 llvm::legacy::PassManager::run(llvm::Module&)
/home/ubuntu/llvm/src/dev.git/lib/IR/LegacyPassManager.cpp:1737:0
#18 0x1313d36c (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
llvm::raw_pwrite_stream*)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/CodeGen/BackendUtil.cpp:767:0
#19 0x1313d704 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
llvm::raw_pwrite_stream*)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/CodeGen/BackendUtil.cpp:783:0
#20 0x13cae848
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/CodeGen/CodeGenAction.cpp:180:0
#21 0x13cae958 clang::ParseAST(clang::Sema&, bool, bool)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/Parse/ParseAST.cpp:167:0
#22 0x14a204cc clang::ASTFrontendAction::ExecuteAction()
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/Frontend/FrontendAction.cpp:557:0
#23 0x15828e28 clang::CodeGenAction::ExecuteAction()
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/CodeGen/CodeGenAction.cpp:851:0
#24 0x1442285c clang::FrontendAction::Execute()
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/Frontend/FrontendAction.cpp:457:0
#25 0x14a1e914
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib/Frontend/CompilerInstance.cpp:876:0
#26 0x14422054
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/home/ubuntu/llvm/src/dev.git/tools/clang/lib

[llvm-bugs] [Bug 28527] New: std::copy() calls memmove on nontrivially-copyable type

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28527

Bug ID: 28527
   Summary: std::copy() calls memmove on nontrivially-copyable
type
   Product: libc++
   Version: 3.8
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: aa...@aaronballman.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified

Consider the following snippet:

#include 

int main() {
  volatile int *v1[100];
  volatile int *v2[100];

  std::copy(v1, v1 + 100, v2);
}

This results in a call to memmove() rather than copying individual volatile
elements of the array (https://godbolt.org/g/b0fv3R). This should be handled a
bit more kindly, since volatile-qualified types are not trivially-copyable
types ([basic.types]p9 states in part: "Cv-unqualified scalar types, trivially
copyable class types (Clause 9), arrays of such types, and nonvolatile
const-qualified versions of these types (3.9.3) are collectively called
trivially copyable types.").

-- 
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 28528] New: Cannot select: intrinsic %llvm.aarch64.neon.sqshrun

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28528

Bug ID: 28528
   Summary: Cannot select: intrinsic %llvm.aarch64.neon.sqshrun
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: AArch64
  Assignee: unassignedb...@nondot.org
  Reporter: alina.sbir...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 16735
  --> https://llvm.org/bugs/attachment.cgi?id=16735&action=edit
Test showing the failure.

We've come across this testcase where the following sequence fails to lower
intrinsic sqshrun.
Fulltest attached (llc test_reduced.ll to reproduce).


  %tmp1906 = add nsw <8 x i32> undef, undef
  %tmp1908 = shufflevector <8 x i32> %tmp1906, <8 x i32> undef, <4 x i32> 
  %tmp1909 = call <4 x i16> @llvm.aarch64.neon.sqshrun.v4i16(<4 x i32>
%tmp1908, i32 18) #0
  %tmp1914 = getelementptr inbounds i16, i16* undef, i64 8
  %tmp1915 = bitcast i16* %tmp1914 to <4 x i16>*
  store <4 x i16> %tmp1909, <4 x i16>* %tmp1915, align 16

-- 
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 28529] New: OrcMCJITReplacement::removeModule does not work as expected

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28529

Bug ID: 28529
   Summary: OrcMCJITReplacement::removeModule does not work as
expected
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: OrcJIT
  Assignee: unassignedb...@nondot.org
  Reporter: aamir.va...@algocell.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

OrcMCJITReplacement does not override ExecutionEngine::removeModule. This
appears to prevent the use-case of adding a module, compiling, running and then
removing the module, using ExecutionEngine. 

The patch appears to be to implement OrcMCJITReplacement::removeModule and
include a call to LazyEmitLayer.removeModuleSet

Note there is an added complication that OrcMCJITReplacement::addModule calls
LazyEmitLayer.addModuleSet without returning the resulting ModuleSetHandleT,
but this value is needed for calling LazyEmitLayer.removeModuleSet

-- 
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 28530] New: [AArch64] recognize the shufflevector equivalent of a vector select

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28530

Bug ID: 28530
   Summary: [AArch64] recognize the shufflevector equivalent of a
vector select
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: AArch64
  Assignee: unassignedb...@nondot.org
  Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

$ cat shufsel.ll 
define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) {
  %sel = select <4 x i1> , <4 x i32> %a,
<4 x i32> %b
  ret <4 x i32> %sel
}

define <4 x i32> @goo(<4 x i32> %a, <4 x i32> %b) {
  %shuf = shufflevector <4 x i32> %a, <4 x i32> %b, <4 x i32> 
  ret <4 x i32> %shuf
}

I'm guessing that one of these is generally better than the other (and there
may be a better way than either of these?):

$ ./llc shufsel.ll -o - -mtriple=aarch64
.LCPI0_0:
.word4294967295  // 0x
.word0   // 0x0
.word0   // 0x0
.word4294967295  // 0x
foo:
adrpx8, .LCPI0_0
ldrq2, [x8, :lo12:.LCPI0_0]
bslv2.16b, v0.16b, v1.16b
movv0.16b, v2.16b
ret
goo:// @goo
extv1.16b, v0.16b, v1.16b, #12
extv0.16b, v1.16b, v0.16b, #4
extv1.16b, v1.16b, v1.16b, #8
extv0.16b, v0.16b, v1.16b, #12
ret

Note that in http://reviews.llvm.org/D22114 , there's a proposal to
canonicalize to the shufflevector form of the IR.

-- 
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 25413] libc++'s string::assign isn't O(1) when assigning the string to itself if the system's memmove() doesn't check for that

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25413

Marshall Clow (home)  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Marshall Clow (home)  ---
Closing as "wontfix", since the problem has been fixed for a few years in the
underlying C library.

If you think that this is something that needs to be addressed, please reopen.

-- 
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 28531] New: [PPC] recognize the shufflevector equivalent of a vector select

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28531

Bug ID: 28531
   Summary: [PPC] recognize the shufflevector equivalent of a
vector select
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: PowerPC
  Assignee: unassignedb...@nondot.org
  Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

$ cat shufsel.ll 
define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) {
  %sel = select <4 x i1> , <4 x i32> %a,
<4 x i32> %b
  ret <4 x i32> %sel
}

define <4 x i32> @goo(<4 x i32> %a, <4 x i32> %b) {
  %shuf = shufflevector <4 x i32> %a, <4 x i32> %b, <4 x i32> 
  ret <4 x i32> %shuf
}

These are functionally equivalent. Note that in http://reviews.llvm.org/D22114
, there's a proposal to canonicalize to the shufflevector form of the IR.

We generate 'xxsel' and 'vperm' for a target with VSX. Is one better than the
other?

For an altivec target, the lowering to vsel is missed:

$ ./llc shufsel.ll -o - -mtriple=powerpc64 -mattr=altivec
foo:# @foo
addis 3, 2, .LCPI0_0@toc@ha
addis 4, 2, .LCPI0_1@toc@ha
addi 3, 3, .LCPI0_0@toc@l
addi 4, 4, .LCPI0_1@toc@l
lvx 4, 0, 3
lvx 5, 0, 4
vand 3, 3, 4
vand 2, 2, 5
vor 2, 2, 3
blr

-- 
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 28532] New: compiler-rt download link is broken

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28532

Bug ID: 28532
   Summary: compiler-rt download link is broken
   Product: new-bugs
   Version: 3.8
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: schnet...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The 3.8.1 release download points to
, which does not
exist.

-- 
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 28533] New: IPSCCP doesn't propagate structs

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28533

Bug ID: 28533
   Summary: IPSCCP doesn't propagate structs
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Interprocedural Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Testcase:

define internal { i32, i32 } @foo(i32 %A, i32 %B) {
%X = add i32 %A, %B
%Y = insertvalue { i32, i32 } undef, i32 %A, 0
%Z = insertvalue { i32, i32 } %Y, i32 %X, 1
ret { i32, i32 } %Z
}

define void @caller(i1 %C) {
%S1 = call { i32, i32 } @foo(i32 1, i32 2)
%X1 = extractvalue { i32, i32 } %S1, 0
%S2 = call { i32, i32 } @foo(i32 3, i32 4)
%X2 = extractvalue { i32, i32 } %S2, 0
%Z  = add i32 %X1, %X2
ret void
}


[davide@localhost build-clang]$ ./bin/opt ./bin/patatellomio.ll -S -ipsccp
; ModuleID = './bin/patatellomio.ll'
source_filename = "./bin/patatellomio.ll"

define internal { i32, i32 } @foo(i32 %A, i32 %B) {
  %X = add i32 %A, %B
  %Y = insertvalue { i32, i32 } undef, i32 %A, 0
  %Z = insertvalue { i32, i32 } %Y, i32 %X, 1
  ret { i32, i32 } %Z
}

define void @caller(i1 %C) {
  %S1 = call { i32, i32 } @foo(i32 1, i32 2)
  %X1 = extractvalue { i32, i32 } %S1, 0
  %S2 = call { i32, i32 } @foo(i32 3, i32 4)
  %X2 = extractvalue { i32, i32 } %S2, 0
  %Z = add i32 %X1, %X2
  ret void
}


define internal { i32, i32 } @foo(i32 %A, i32 %B) {
  %X = add i32 %A, %B
  %Y = insertvalue { i32, i32 } undef, i32 %A, 0
  %Z = insertvalue { i32, i32 } %Y, i32 %X, 1
  ret { i32, i32 } %Z
}

define void @caller(i1 %C) {
  %S1 = call { i32, i32 } @foo(i32 1, i32 2)
  %S2 = call { i32, i32 } @foo(i32 3, i32 4)
  %Z = add i32 1, 3
  ret void
}

-- 
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 24988] gcc -Wattribute warnings for several libc++ headers

2016-07-12 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=24988

Marshall Clow (home)  changed:

   What|Removed |Added

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

--- Comment #2 from Marshall Clow (home)  ---
I just tried this with gcc 6.1.0, and have the same problems.

I'm closing this as invalid, since it's a GCC bug.

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