date:20170915

[llvm-bugs] [Bug 34622] New: Assertion failure in clang::ento::SValBuilder::evalBinOp

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34622

Bug ID: 34622
   Summary: Assertion failure in
clang::ento::SValBuilder::evalBinOp
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: ale...@google.com
CC: llvm-bugs@lists.llvm.org

$ echo "void crash(bool *b) { EXPECT_TRUE(*b); }" >>
llvm.git/tools/clang/test/Analysis/gtest.cpp
$ clang-tidy llvm.git/tools/clang/test/Analysis/gtest.cpp
-checks=-*,clang-analyzer-apiModeling.google.GTest -- -std=c++11
-DGTEST_VERSION_1_8_AND_LATER=1
assert.h assertion failed at
tools/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:406 in clang::ento::SVal
clang::ento::SValBuilder::evalBinOp(clang::ento::ProgramStateRef,
BinaryOperator::Opcode, clang::ento::SVal, clang::ento::SVal, clang::QualType):
op == BO_Add
@  0x52d94ca  __assert_fail
@  0x2c26793  clang::ento::SValBuilder::evalBinOp()
@  0x2c26a41  clang::ento::SValBuilder::evalEQ()
@  0x2a50428  (anonymous
namespace)::GTestChecker::assumeValuesEqual()
@  0x2a50015  (anonymous
namespace)::GTestChecker::modelAssertionResultBoolConstructor()
@  0x2a4f9bb  (anonymous namespace)::GTestChecker::checkPostCall()
@  0x2a4f780  clang::ento::check::PostCall::_checkCall<>()
@  0x2d01842  clang::ento::CheckerFn<>::operator()()
@  0x2cf537a  (anonymous namespace)::CheckCallContext::runChecker()
@  0x2cf2489  expandGraphWithCheckers<>()
@  0x2cf2200 
clang::ento::CheckerManager::runCheckersForCallEvent()
@  0x2d55b48  clang::ento::CheckerManager::runCheckersForPostCall()
@  0x2d53a10  clang::ento::ExprEngine::VisitCXXConstructExpr()
@  0x2d10d99  clang::ento::ExprEngine::Visit()
@  0x2d0dcd1  clang::ento::ExprEngine::ProcessStmt()
@  0x2d0d98a  clang::ento::ExprEngine::processCFGElement()
@  0x2d3bff6  clang::ento::CoreEngine::HandlePostStmt()
@  0x2d3b8f6  clang::ento::CoreEngine::dispatchWorkItem()
@  0x2d3b458  clang::ento::CoreEngine::ExecuteWorkList()
@  0x20309f5  clang::ento::ExprEngine::ExecuteWorkList()
@  0x1fd8192  (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@  0x1fd7f51  (anonymous
namespace)::AnalysisConsumer::RunPathSensitiveChecks()
@  0x1fd7c15  (anonymous namespace)::AnalysisConsumer::HandleCode()
@  0x1fcb113  (anonymous
namespace)::AnalysisConsumer::HandleDeclsCallGraph()
@  0x1fc9397  (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@  0x240173e  clang::MultiplexConsumer::HandleTranslationUnit()
@  0x2e58606  clang::ParseAST()
@  0x23ef10a  clang::ASTFrontendAction::ExecuteAction()
@  0x23eeba0  clang::FrontendAction::Execute()

-- 
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 34620] New: redundant pand after vector shift of a byte vector (psrlw)

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34620

Bug ID: 34620
   Summary: redundant pand after vector shift of a byte vector
(psrlw)
   Product: libraries
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: l...@henning-thielemann.de
CC: llvm-bugs@lists.llvm.org

I have a vector of bytes and want to increment the vector elements according to
certain bits of another vector like so:

define <16 x i8> @add_bitset_to_vector(<16 x i8>, <16 x i8>) {
_L1:
  %v0 = lshr <16 x i8> %0, 
  %v1 = and <16 x i8> %v0, 
  %v2 = add <16 x i8> %v1, %1
  ret <16 x i8> %v2
}


On X86-64 llc emits:

.section.rodata.cst16,"aM",@progbits,16
.p2align4
.LCPI2_0:
.zero   16,127
.LCPI2_1:
.zero   16,1
.text
.globl  add_bitset_to_vector
.p2align4, 0x90
.type   add_bitset_to_vector,@function
add_bitset_to_vector:   # @add_bitset_to_vector
# BB#0: # %_L1
psrlw   $1, %xmm0
pand.LCPI2_0(%rip), %xmm0
pand.LCPI2_1(%rip), %xmm0
paddb   %xmm1, %xmm0
retq
.Lfunc_end2:
.size   add_bitset_to_vector, .Lfunc_end2-add_bitset_to_vector


That is, the X86 backend uses word vector shift (psrlw) plus pand in order to
perform the byte vector shift. However, my pand for masking the least
significant bits makes the pand generated by lshr redundant.

-- 
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 34621] New: Support for saturated vector increment

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34621

Bug ID: 34621
   Summary: Support for saturated vector increment
   Product: libraries
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: l...@henning-thielemann.de
CC: llvm-bugs@lists.llvm.org

I have a special case of https://bugs.llvm.org/show_bug.cgi?id=14613 .
I add a vector to another vector but the first operand contains only zeros and
ones.

define <16 x i8> @increment_vector_sat(<16 x i8>, <16 x i8>) {
_L1:
  %v0 = and <16 x i8> %0, 
  %v1 = add <16 x i8> %v0, %1
  %b = icmp ult <16 x i8> %1, 
  %v2 = select <16 x i1> %b, <16 x i8> %v1, <16 x i8> %1
  ret <16 x i8> %v2
}


$ opt-4.0 -O3 < bit-vector.ll | llc-4.0

.section.rodata.cst16,"aM",@progbits,16
.p2align4
.LCPI5_0:
.zero   16,1
.text
.globl  increment_vector_sat
.p2align4, 0x90
.type   increment_vector_sat,@function
increment_vector_sat:   # @increment_vector_sat
# BB#0: # %_L1
pand.LCPI5_0(%rip), %xmm0
paddb   %xmm1, %xmm0
pcmpeqd %xmm2, %xmm2
pcmpeqb %xmm1, %xmm2
por %xmm2, %xmm0
retq
.Lfunc_end5:
.size   increment_vector_sat, .Lfunc_end5-increment_vector_sat


Could the X86 backend replace 'paddb' and the following code by a simple
'paddusb'?

An alternative would be a saturated add intrinsics.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 3386 in oss-fuzz: llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable

2017-09-15 Thread monor… via monorail via llvm-bugs


Status: New
Owner: 
CC: k...@google.com,  masc...@google.com,  jdevlieg...@apple.com,   
llvm-b...@lists.llvm.org
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-09-15


New issue 3386 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3386

Detailed report: https://oss-fuzz.com/testcase?key=6263226956251136

Project: llvm
Fuzzer: libFuzzer_llvm_clang-fuzzer
Fuzz target binary: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffe4f0c09a8
Crash State:
  clang::DiagnosticIDs::isUnrecoverable
  clang::DiagnosticIDs::ProcessDiag
  clang::DiagnosticsEngine::EmitCurrentDiagnostic

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201709140449:201709150442


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=6263226956251136


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any  
stable releases.

  * add any other useful information.
This information can help downstream consumers.

If you have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 34606] AddressSanitizer: Failed CHECKs on FreeBSD

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34606

Mikael Simonsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Mikael Simonsson  ---


*** This bug has been marked as a duplicate of bug 34324 ***

-- 
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 34624] New: A template-friend bug of bound friend templates

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34624

Bug ID: 34624
   Summary: A template-friend bug of bound friend templates
   Product: clang
   Version: 4.0
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: C++11
  Assignee: unassignedclangb...@nondot.org
  Reporter: question123...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

First: 
$ clang++ -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /usr/local/bin



I write code as below:

#include 

using namespace std;

//template 
//class A;
//
//template 
//bool operator == (const A & a1, const A & a2);

template 
class A {
friend bool operator ==<> (const A & a1, const A & a2); 
};

template 
bool operator == (const A & a1, const A & a2)
{
return true;
}

int main(int argc, char *argv[]) 
{
A a1, a2;
cout << (a1 == a2) << endl;

//  if (a1 == a2) {
//  cout << ".." << endl;
//  }
}

I used `clang++ -std=c++11 bound\ friend\ templates.cc -o bound\ friend\
templates`.
This can pass the compiler. However, C++ standards don't allow this. We'd use a
declaration to declare the class and the operator == function, as the
annotation above. This is the first bug.

Besides, when I use `./` to run this program, it's interesting to see the
standard output shows nothing instead of `1`. So I cancelled the annotation in
`main` function. Then, clang++ turns to bug.

*** clang++ Error message *

0  clang-4.00x00010f432e1b
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  clang-4.00x00010f4323b3 llvm::sys::RunSignalHandlers() +
83
2  clang-4.00x00010f43323a SignalHandler(int) + 195
3  libsystem_platform.dylib 0x7fff9ebd0b3a _sigtramp + 26
4  libsystem_platform.dylib 0x7fdd13c1fc10 _sigtramp + 1963258096
5  clang-4.00x00010f6033f7 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 43
6  clang-4.00x00010f6033c6
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 50
7  clang-4.00x00010f5dcfb1
clang::CodeGen::CodeGenFunction::EvaluateExprAsBool(clang::Expr const*) + 295
8  clang-4.00x00010f69193f
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr const*,
llvm::BasicBlock*, llvm::BasicBlock*, unsigned long long) + 1857
9  clang-4.00x00010f667440
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 416
10 clang-4.00x00010f66c453
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) + 83
11 clang-4.00x00010f690498
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) + 88
12 clang-4.00x00010f690a7c
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 684
13 clang-4.00x00010f69cf22
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 254
14 clang-4.00x00010f69a77c
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 316
15 clang-4.00x00010f69e29f
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 169
16 clang-4.00x00010f6eabc9 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 125
17 clang-4.00x00010f68acb6
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 180
18 clang-4.00x00010fd00861 clang::ParseAST(clang::Sema&,
bool, bool) + 319
19 clang-4.00x00010f80374a clang::FrontendAction::Execute()
+ 76
20 clang-4.00x00010f7d666b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 605
21 clang-4.00x00010f832398
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3448
22 clang-4.00x00010e6a23b9 cc1_main(llvm::ArrayRef, char const*, void*) + 1337
23 clang-4.00x00010e6a101a main + 8096
24 libdyld.dylib0x7fff9e9c1235 start + 1
25 libdyld.dylib0x0036 start + 1633938946
Stack dump:
0.  Program arguments: /usr/local/Cellar/llvm/4.0.0/bin/clang-4.0 -cc1
-triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name Untitled 2.cpp
-mrelocation-model pic -pic-level 2 -mthread-model posix

[llvm-bugs] [Bug 34626] New: "Hash Sum mismatch" for trusty 'main' packages

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34626

Bug ID: 34626
   Summary: "Hash Sum mismatch" for trusty 'main' packages
   Product: Packaging
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: deb packages
  Assignee: unassignedb...@nondot.org
  Reporter: frederik.dewee...@gmail.com
CC: llvm-bugs@lists.llvm.org

On trusty 14.04, doing:

$ apt-add-repository -y 'deb http://llvm.org/apt/trusty
llvm-toolchain-trusty main'
$ apt-get --yes update

Fails with the following error:

E: Failed to fetch
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/main/binary-amd64/Packages
 Hash Sum mismatch


Indeed when hand downloading
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/InRelease and
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/main/binary-amd64/Packages.gz,
I could verify that the checksum for Packages.gz doesn't match the one
in InRelease.

-- 
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 34623] Folding of select breaks min/max

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34623

Sanjay Patel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
 CC||spatel+l...@rotateright.com

--- Comment #1 from Sanjay Patel  ---
I don't see this bug on trunk; tested with:

$ ./clang -v
clang version 6.0.0 (trunk 313258)
Target: x86_64-apple-darwin16.7.0

$ ./clang -O2 -mavx2 castmax.ll -S -o - |grep minsd

vpminsd %ymm1, %ymm0, %ymm0

Looks fixed in the clang 5.0 release as well:
https://godbolt.org/g/zXGhL4

-- 
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 34630] New: __builtin_offsetof doesn't allow scope qualifiers

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34630

Bug ID: 34630
   Summary: __builtin_offsetof doesn't allow scope qualifiers
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: myriac...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

The following code does not compile, with a syntax error:

#include 

struct A { int x; };
struct B { };
struct C : A, B { };

int meow()
{
  return offsetof(C, A::x);
}

error: expected ')'

Whether this should be allowed in C++ is an interesting question.  C++ defers
to C, which says a "member-designator" here, but then doesn't define that. 
(There's a WG14 defect report somewhere on this, to be fixed for C2x?)

Normally, this wouldn't be necessary, because the first parameter should be a
standard-layout type, which can't have non-static members of conflicting names.
 But pretty much every compiler supports offsetof() on everything but virtual
inheritance cases, so people use it.  (Also, there's a C++ proposal in the
works to formally allow offsetof for any class not involving the word
"virtual".)

GCC allows 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 34403] Assertion failure in RetainSummaryManager::getFunctionSummary()

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34403

George Karpenkov  changed:

   What|Removed |Added

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

--- Comment #10 from George Karpenkov  ---
Pushed to trunk, should be working now.

-- 
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 28903] Segmentation fault in CXXRecordDecl::getFirstFriend

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=28903

Volodymyr Sapsai  changed:

   What|Removed |Added

 Fixed By Commit(s)||313386
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Volodymyr Sapsai  ---
Fixed in r313386.

-- 
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 28154] [meta] Add support for CodeView, the MSVC-compatible debug information format

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=28154
Bug 28154 depends on bug 30978, which changed state.

Bug 30978 Summary: [codeview] Emit file checksums
https://bugs.llvm.org/show_bug.cgi?id=30978

   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 30978] [codeview] Emit file checksums

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=30978

Eric Beckmann  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Beckmann  ---
Fixed in r313374

-- 
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 34629] New: New assertion: "getVRegDef assumes a single definition or no definition" after r313343

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34629

Bug ID: 34629
   Summary: New assertion: "getVRegDef assumes a single definition
or no definition" after r313343
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org

See https://bugs.chromium.org/p/chromium/issues/detail?id=765748#c1 for repro.

-- 
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 34301] lld drops the weak symbol

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34301

Rafael Ávila de Espíndola  changed:

   What|Removed |Added

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

--- Comment #13 from Rafael Ávila de Espíndola  ---
Fixed in r313372.

-- 
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 34619] Instruction does not dominate all uses!

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34619

Davide Italiano  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dav...@freebsd.org
 Resolution|--- |FIXED

--- Comment #4 from Davide Italiano  ---
Fixed with the revert, please include this case if you plan to commit again.

-- 
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 34605] [m32][skx] clang fails differently on X86 DAG->DAG Instruction Selection

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34605

Simon Pilgrim  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||h...@chromium.org,
   ||tstel...@redhat.com
 Resolution|FIXED   |---

--- Comment #3 from Simon Pilgrim  ---
Reopening until its merged into 5.0.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 34492] [meta] 5.0.1 Release Blockers

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34492
Bug 34492 depends on bug 34605, which changed state.

Bug 34605 Summary: [m32][skx] clang fails differently on X86 DAG->DAG 
Instruction Selection
https://bugs.llvm.org/show_bug.cgi?id=34605

   What|Removed |Added

 Status|RESOLVED|REOPENED
 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 34619] New: Instruction does not dominate all uses!

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34619

Bug ID: 34619
   Summary: Instruction does not dominate all uses!
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Transformation Utilities
  Assignee: unassignedb...@nondot.org
  Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19158
  --> https://bugs.llvm.org/attachment.cgi?id=19158=edit
reduced testcase

It seems that trunk@313348 showed up in a git bisect for the following crash
with opt:

bin/opt -S -O3 -mtriple=systemz-unknown -mcpu=z13 tc_domuses.ll -o out.ll
Instruction does not dominate all uses!
  %10 = load i32, i32* getelementptr inbounds ([4 x [4 x i32]], [4 x [4 x
i32]]* @dct_luma.m4, i64 0, i64 3, i64 0), align 4, !tbaa !1
  %3 = insertelement <4 x i32> undef, i32 %10, i32 0
Instruction does not dominate all uses!
  %11 = load i32, i32* getelementptr inbounds ([4 x [4 x i32]], [4 x [4 x
i32]]* @dct_luma.m4, i64 0, i64 3, i64 2), align 4, !tbaa !1
  %5 = insertelement <4 x i32> %4, i32 %11, i32 2
Instruction does not dominate all uses!
  %12 = load i32, i32* getelementptr inbounds ([4 x [4 x i32]], [4 x [4 x
i32]]* @dct_luma.m4, i64 0, i64 3, i64 3), align 4, !tbaa !1
  %6 = insertelement <4 x i32> %5, i32 %12, i32 3
LLVM ERROR: Broken function found, compilation 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 34502] Regalloc assert fails: Unexpected VNI

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34502

Jonas Paulsson  changed:

   What|Removed |Added

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

--- Comment #8 from Jonas Paulsson  ---
Recommited as r313349.

-- 
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 25264] Segfault when using undefined variable in lambda that is assigned to std::function

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=25264

gereon.kre...@cs.rwth-aachen.de changed:

   What|Removed |Added

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

--- Comment #3 from gereon.kre...@cs.rwth-aachen.de ---
This seems to be fixed as of clang 4.0.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 34634] clang crashes on valid code at -O1 and above: Assertion `(I.atEnd() || std::next(I) == def_instr_end()) && "getVRegDef assumes a single definition or no definition"' failed

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34634

Zhendong Su  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 34631] New: [X86] Using _mm512_maskz_set1_epi64 on a 32-bit build causes cannot select intrinsic error

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34631

Bug ID: 34631
   Summary: [X86] Using _mm512_maskz_set1_epi64  on a 32-bit build
causes cannot select intrinsic error
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Headers
  Assignee: unassignedclangb...@nondot.org
  Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org

This intrinsic is currently implemented in clang by selecting between two
different builtins, __builtin_ia32_pbroadcastq512_gpr_mask(64-bit) and
__builtin_ia32_pbroadcastq512_mem_mask(32-bit). 

But it seems __builtin_ia32_pbroadcastq512_mem_mask was never implemented in
the X86 backend. So using it just causes an isel error. And worse, on a debug
build it hits an llvm_unreachable trying to expand a 64-bit operand on an
intrinsic.


Test case

#include 

__m512i test_mm512_maskz_set1_epi64 (__mmask8 __M, long long __A)
{
//CHECK-LABEL: @test_mm512_maskz_set1_epi64
//CHECK: @llvm.x86.avx512.mask.pbroadcast.q.gpr.512
  return _mm512_maskz_set1_epi64 (__M, __A);
}

-- 
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 34632] New: Strict-aliasing not noticing valid aliasing of two unions with active members

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34632

Bug ID: 34632
   Summary: Strict-aliasing not noticing valid aliasing of two
unions with active members
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: myriac...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Consider the following C/C++ code with -O3 -fstrict-aliasing:

struct s1 {unsigned short x;};
struct s2 {unsigned short x;};
union s1s2 { struct s1 v1; struct s2 v2; };

static int read_s1x(struct s1 *p) { return p->x; }
static void write_s2x(struct s2 *p, int v) { p->x=v;}

int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
{
  if (read_s1x(>v1))
  {
unsigned short temp;
temp = p3->v1.x;
p3->v2.x = temp;
write_s2x(>v2,1234);
temp = p3->v2.x;
p3->v1.x = temp;
  }
  return read_s1x(>v1);
}
int test2(int x)
{
  union s1s2 q[2];
  q->v1.x = 4321;
  return test(q,q+x,q+x);
}
#include 
int main(void)
{
  printf("%d\n",test2(0));
}

Clang (and GCC) generate code that outputs 4321 instead of the expected 1234.

I don't really understand things in terms of the C standard, but in terms of
the C++ standard, it seems as if Clang and GCC are incorrect, and this code is
well-defined.  (The output is 4321 in both C and C++ mode.)

According to [class.union]/5 in the C++17 draft N4659, the assignment
expression "p3->v2.x = temp;" changes the active member of the union.  It's
done through a union member access expression.  Thus the pointer >v2 is
valid here.

Even if I switch this to "p3->v2 = { x };", avoiding the nested case, the
problem still happens.

Even if I explicitly change the active member of the union with placement new
as "new() s2;", the problem still happens.

Is it possible that Clang doesn't see the possibility that p2 and p3 point to
the same object?

-- 
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 34627] InstCombine fails when constant folding gep with vector result: Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"'

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34627

Davide Italiano  changed:

   What|Removed |Added

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

--- Comment #11 from Davide Italiano  ---
r313394, 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 28518] fatal error: error in backend: Cannot select: intrinsic %llvm.x86.bmi.pdep.32

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=28518

Craig Topper  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||craig.top...@gmail.com
 Resolution|--- |INVALID

--- Comment #2 from Craig Topper  ---
I'm going to resolve this as invalid. I think we're pretty good about checking
this in trunk.

-- 
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 21691] [META] Compiling the Coreboot with clang

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=21691
Bug 21691 depends on bug 23237, which changed state.

Bug 23237 Summary: fatal error: error in backend: Cannot select: intrinsic 
%llvm.x86.sse2.mfence
https://bugs.llvm.org/show_bug.cgi?id=23237

   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 23237] fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse2.mfence

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=23237

Craig Topper  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||craig.top...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Craig Topper  ---
I suspect this occured because mmx was disabled which used to automaticall
disable SSE. That was fixed in r249733. That looks to be after 3.7 released.

-- 
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 34634] New: clang crashes on valid code at -O1 and above: Assertion `(I.atEnd() || std::next(I) == def_instr_end()) && "getVRegDef assumes a single definition or no definition"' faile

2017-09-15 Thread via llvm-bugs

;, llvm::detail::DenseMapPair<(anonymous
namespace)::MemOpKey, std::__cxx11::list<llvm::MachineInstr*,
std::allocator<llvm::MachineInstr*> > > const*&) const [clone .constprop.260]
/home/su/software/tmp/polly/llvm/include/llvm/ADT/DenseMap.h:591:0
#12 0x0150e912 find
/home/su/software/tmp/polly/llvm/include/llvm/ADT/DenseMap.h:148:0
#13 0x0150e912 popScope
/home/su/software/tmp/polly/llvm/lib/Target/X86/X86OptimizeLEAs.cpp:390:0
#14 0x0150e912 (anonymous
namespace)::OptimizeLEAPass::FactorizeLEAsBasicBlock(llvm::DomTreeNodeBase*)
[clone .constprop.242]
/home/su/software/tmp/polly/llvm/lib/Target/X86/X86OptimizeLEAs.cpp:1029:0
#15 0x01510d1c FactorizeLEAsAllBasicBlocks
/home/su/software/tmp/polly/llvm/lib/Target/X86/X86OptimizeLEAs.cpp:1034:0
#16 0x01510d1c (anonymous
namespace)::OptimizeLEAPass::runOnMachineFunction(llvm::MachineFunction&)
[clone .part.225] [clone .constprop.229]
/home/su/software/tmp/polly/llvm/lib/Target/X86/X86OptimizeLEAs.cpp:1051:0
#17 0x0185f255
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/home/su/software/tmp/polly/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0
#18 0x01b6ee7b llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1514:0
#19 0x01b6ef3c llvm::FPPassManager::runOnModule(llvm::Module&)
/home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1535:0
#20 0x01b6ea7d runOnModule
/home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1591:0
#21 0x01b6ea7d llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1694:0
#22 0x0219e03f llvm::PrettyStackTraceString::~PrettyStackTraceString()
/home/su/software/tmp/polly/llvm/include/llvm/Support/PrettyStackTrace.h:52:0
#23 0x0219e03f EmitAssembly
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:793:0
#24 0x0219e03f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete >)
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1145:0
#25 0x02993bc9 std::unique_ptr<llvm::raw_pwrite_stream,
std::default_delete >::~unique_ptr()
/usr/include/c++/5/bits/unique_ptr.h:235:0
#26 0x02993bc9
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:261:0
#27 0x02b61188 void std::swap(bool&, bool&)
/usr/include/c++/5/bits/move.h:187:0
#28 0x02b61188 clang::ParseAST(clang::Sema&, bool, bool)
/home/su/software/tmp/polly/llvm/tools/clang/lib/Parse/ParseAST.cpp:161:0
#29 0x029930bf clang::CodeGenAction::ExecuteAction()
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:993:0
#30 0x0253f4e6 clang::FrontendAction::Execute()
/home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:897:0
#31 0x0250fd26
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:991:0
#32 0x025cd4d2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/home/su/software/tmp/polly/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252:0
#33 0x00a7bf78 cc1_main(llvm::ArrayRef, char const*,
void*)
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/cc1_main.cpp:221:0
#34 0x009f9fe8 ExecuteCC1Tool
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:302:0
#35 0x009f9fe8 main
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:381:0
#36 0x7f00af35e830 __libc_start_main
/build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:325:0
#37 0x00a78899 _start
(/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0xa78899)
Stack dump:
0.  Program arguments: /home/su/software/tmp/polly/llvm_build/bin/clang-6.0
-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 -dwarf-column-info -debugger-tuning=gdb
-momit-leaf-frame-pointer -resource-dir
/home/su/software/tmp/polly/llvm_build/lib/clang/6.0.0 -internal-isystem
/usr/local/include -internal-isystem
/home/su/software/tmp/polly/llvm_build/lib/clang/6.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O1
-fdebug-compilation-dir
/home/su/projects/c-hunter-latest/test/compilertesting/scripts/specu

[llvm-bugs] [Bug 34635] New: r312791 causes SLP vectorizer to miscompile signed int min reductions

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34635

Bug ID: 34635
   Summary: r312791 causes SLP vectorizer to miscompile signed int
min reductions
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: chandl...@gmail.com
CC: llvm-bugs@lists.llvm.org

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

Test case attached. To reproduce:

% llc < slp_test.ll | clang -x assembler - -o slp_test.good && ./slp_test.good
minidx = 5

% opt < slp_test.ll -passes=slp-vectorizer | llc | clang -x assembler - -o
slp_test.bad && ./slp_test.bad
minidx = 6


I'm going to revert for now.

-- 
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 34513] Missing DW_OP_deref for non-trivial return by value

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34513

Reid Kleckner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Assignee|apra...@apple.com   |r...@google.com
 Resolution|--- |FIXED

--- Comment #5 from Reid Kleckner  ---
After r313400 and r313399 this should work both in -O0 and in many cases when
optimized. I added a debuginfo-tests test in r313401, so hopefully this doesn't
regress.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 3390 in oss-fuzz: llvm: ASSERT: IndentPrefix.startswith("//")

2017-09-15 Thread monor… via monorail via llvm-bugs


Status: New
Owner: 
CC: k...@google.com,  masc...@google.com,  jdevlieg...@apple.com,   
llvm-b...@lists.llvm.org
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-09-15


New issue 3390 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm: ASSERT: IndentPrefix.startswith("//")

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3390

Detailed report: https://oss-fuzz.com/testcase?key=6378093373554688

Project: llvm
Fuzzer: libFuzzer_llvm_clang-format-fuzzer
Fuzz target binary: clang-format-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  IndentPrefix.startswith("//")
  clang::format::BreakableLineCommentSection::BreakableLineCommentSection
  clang::format::ContinuationIndenter::breakProtrudingToken

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201709130450:201709140449


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=6378093373554688


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any  
stable releases.

  * add any other useful information.
This information can help downstream consumers.

If you have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 34633] New: LLVMDumpType() #ifdefed

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34633

Bug ID: 34633
   Summary: LLVMDumpType() #ifdefed
   Product: libraries
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Core LLVM classes
  Assignee: unassignedb...@nondot.org
  Reporter: ken.dom...@gmail.com
CC: llvm-bugs@lists.llvm.org

In LLVM-C, there is a definition for LLVMDumpType(), and it's documented.
LLVMDumpType() is defined in .../lib/ir/Core.cpp and
.../llvm/include/llvm-c/Core.h. LLVMDumpType() as well as LLVMDumpValue() were
#ifdef'ed on Jan 27 2917 by MatzeB. The #ifdef for LLVMDumpValue() was undone
Jan 30 2017 by sam-mccall, but LLVMDumpType() was not. Can someone please clean
this up? Remove the #ifdef's for LLVMDumpType() and make it consistent with
LLVMDumpValue(). If it's not supposed to be in the API, remove this and
LLVMDumpValue() completely. The API shouldn't be promising something in a
header file and not deliver something in the binary at least something, even if
a stub.

-- 
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 18888] Cannot select: intrinsic %llvm.x86.sse42.crc32.32.8

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=1

Craig Topper  changed:

   What|Removed |Added

 CC||craig.top...@gmail.com
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Craig Topper  ---
Resolving as invalid. This looks to have been compiled without enabling support
CRC32 feature either through -march or -mcrc32. We generally tell people not
use the builtin directly and instead to use the intrinsic in x86intrin.h

At the time this was filed using the intrinsic should have given a compile
error that the intrinsic wouldn't be defined without enabling crc32. Current
version of clang should detect the missing feature support on the builtin even
without using the intrinsic.

-- 
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 34636] New: make -fsanitize-coverage=pc-table friendly with -ffunction-sections -Wl, -gc-sections

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34636

Bug ID: 34636
   Summary: make -fsanitize-coverage=pc-table friendly with
-ffunction-sections -Wl,-gc-sections
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: masc...@google.com
  Reporter: k...@google.com
CC: ekarpen...@apple.com, eugeni.stepa...@gmail.com,
llvm-b...@justinbogner.com, llvm-bugs@lists.llvm.org,
pe...@pcc.me.uk

[discussed previously at
http://lists.llvm.org/pipermail/llvm-dev/2017-September/117315.html]


On linux we have two problems with -fsanitize=fuzzer and -ffunction-sections
-Wl,-gc-sections

Test for these: projects/compiler-rt/test/fuzzer/GcSectionsTest.cpp

First problem: 

% clang -std=c++11 -ffunction-sections -Wl,-gc-sections -fsanitize=fuzzer 
GcSectionsTest.cpp 
/tmp/GcSectionsTest-065286.o: In function `sancov.module_ctor':
GcSectionsTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x22):
undefined reference to `__start___sancov_pcs'
GcSectionsTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x2c):
undefined reference to `__stop___sancov_pcs'

Here, the table produced by -fsanitize-coverage=pc-table __sancov_pcs gets
dropped by the bfd linker (on Ubuntu 14.04). 

With a better linker (-fuse-ld=gold or -fuse-ld=lld) this doesn't happen,
but we still *may* need to find a workaround suitable for old ld. Or maybe not. 


Second:

% clang -std=c++11 -ffunction-sections -Wl,-gc-sections -fsanitize=fuzzer 
GcSectionsTest.cpp -fuse-ld=lld && nm a.out | grep Unused 
0023f590 t UnusedFunctionShouldBeRemovedByLinker


here, gc-sections is essentially disabled because -fsanitize-coverage=pc-table
makes all functions used. 

eugenis@ suggests that all we need here is to use
https://llvm.org/docs/LangRef.html#associated-metadata to mark the pc-table as
associated with it's function. 

This is important, we need gc-sections to work. 
But once we fix it, we'll need a test (in test/fuzzer/gc-sections.test)
but the test won't work with bfd linker, see above.

-- 
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 34637] New: Correctly output file checksums in hex form

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34637

Bug ID: 34637
   Summary: Correctly output file checksums in hex form
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: ecbeckm...@google.com
CC: llvm-bugs@lists.llvm.org

r313374 added code to output the file checksums into the object file.  However
there is a bug where the STRING of the checksum is outputted instead of the
actual hex bytes.  This prevent pdbs from being loaded by Visual Studio.  This
was reverted in r313431.  This bug needs to be fixed and then the checksum
patch can re-land.

-- 
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 34638] New: clang crashes when building "complex" code with a plugin

2017-09-15 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=34638

Bug ID: 34638
   Summary: clang crashes when building "complex" code with a
plugin
   Product: clang
   Version: 5.0
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: xax...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

When I try to run my clang plugin on my real codebase, it crashes.   I can
compile the code without the plugin and I can run the plugin on some (much)
simpler code.

Zacs-MacBook-Air:js-api xaxxon$ time
/Users/xaxxon/Downloads/clang+llvm-5.0.0/bin/clang++ 
-DV8TOOLKIT_ENABLE_EASTL_SUPPORT -DV8TOOLKIT_WRAPPER_FAST_COMPILE
-I/usr/local/include/SDL2 -I/Users/xaxxon/apb/. -I/Users/xaxxon/apb/include
-I/usr/local/include -I/Users/xaxxon/apb -I/Users/xaxxon/apb/glm
-I/Users/xaxxon/apb/js-api/apb-js-api-template -I/Users/xaxxon/v8/include 
-std=gnu++1z -target x86_64-apple-darwin15.6.0
-Wno-aligned-allocation-unavailable -pedantic -Werror=return-type -msse4.1
-stdlib=libc++ -Xclang -load -Xclang
/Users/xaxxon/apb/cmake-build-debug/js-api/libclass_parser_plugin.dylib
-fsyntax-only -Xclang -plugin -Xclang v8toolkit-generate-bindings  -g   -o
CMakeFiles/apb-js-api.dir/cotire/apb-js-api-template_CXX_unity.cxx.o -c
/Users/xaxxon/apb/cmake-build-debug/js-api/cotire/apb-js-api-template_CXX_unity.cxx
0  clang-5.00x00010d54b1f8
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  clang-5.00x00010d54b7a6 SignalHandler(int) + 342
2  libsystem_platform.dylib 0x7fff9917152a _sigtramp + 26
3  libsystem_platform.dylib 0x81a0796d81a0796d _sigtramp + 3901318237
4  libclass_parser_plugin.dylib 0x000111b78f18
handleFloatFloatBinOp((anonymous namespace)::EvalInfo&, clang::Expr const*,
llvm::APFloat&, clang::BinaryOperatorKind, llvm::APFloat const&) + 280
5  libclass_parser_plugin.dylib 0x000111b77e6f (anonymous
namespace)::FloatExprEvaluator::VisitBinaryOperator(clang::BinaryOperator
const*) + 703
6  libclass_parser_plugin.dylib 0x000111b79d93 (anonymous
namespace)::FloatExprEvaluator::VisitCastExpr(clang::CastExpr const*) + 195
7  libclass_parser_plugin.dylib 0x000111b77c4f (anonymous
namespace)::FloatExprEvaluator::VisitBinaryOperator(clang::BinaryOperator
const*) + 159
8  libclass_parser_plugin.dylib 0x000111b79d93 (anonymous
namespace)::FloatExprEvaluator::VisitCastExpr(clang::CastExpr const*) + 195
9  libclass_parser_plugin.dylib 0x000111b77c4f (anonymous
namespace)::FloatExprEvaluator::VisitBinaryOperator(clang::BinaryOperator
const*) + 159
10 libclass_parser_plugin.dylib 0x000111b4ee4c Evaluate(clang::APValue&,
(anonymous namespace)::EvalInfo&, clang::Expr const*) + 796
11 libclass_parser_plugin.dylib 0x000111b58aa5 (anonymous
namespace)::LValueExprEvaluator::VisitCompoundAssignOperator(clang::CompoundAssignOperator
const*) + 389
12 libclass_parser_plugin.dylib 0x000111b4ebe1 Evaluate(clang::APValue&,
(anonymous namespace)::EvalInfo&, clang::Expr const*) + 177
13 libclass_parser_plugin.dylib 0x000111b4aefc EvaluateAsRValue((anonymous
namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) + 92
14 libclass_parser_plugin.dylib 0x000111b4ccaf
clang::Expr::EvaluateForOverflow(clang::ASTContext const&) const + 415
15 libclass_parser_plugin.dylib 0x0001112c53f4
clang::Sema::CheckForIntOverflow(clang::Expr*) + 260
16 libclass_parser_plugin.dylib 0x0001112c5699
clang::Sema::CheckCompletedExpr(clang::Expr*, clang::SourceLocation, bool) + 89
17 libclass_parser_plugin.dylib 0x00011153b1c1
clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool,
bool, bool) + 289
18 libclass_parser_plugin.dylib 0x00011168fa26
clang::Sema::ActOnExprStmt(clang::ActionResult) + 54
19 libclass_parser_plugin.dylib 0x000111a0d84d
clang::Parser::ParseExprStatement() + 573
20 libclass_parser_plugin.dylib 0x000111a0c1e5
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&) + 869
21 libclass_parser_plugin.dylib 0x000111a0bd64
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*) + 180
22 libclass_parser_plugin.dylib 0x000111a12b59
clang::Parser::ParseCompoundStatementBody(bool) + 1561
23 libclass_parser_plugin.dylib 0x0001119db805
clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) +
2581
24 libclass_parser_plugin.dylib 0x0001119da259
clang::Parser::ParseLambdaExpression() + 377
25 libclass_parser_plugin.dylib 0x0001119caace
clang::Parser::ParseCastExpression(bool, bool, bool&,

37 matches

Mail list logo