[llvm-bugs] [Bug 35007] New: Clang-format comment alignment issue

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35007

Bug ID: 35007
   Summary: Clang-format comment alignment issue
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: amaca...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

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

Running clang-format with -style=file -i over attached C source file, with
attached .clang-format results in what I believe to be a wrong alignment for
line 7

-- 
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 35008] New: clang-format unwanted extra line added after #define

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35008

Bug ID: 35008
   Summary: clang-format unwanted extra line added after #define
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: amaca...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

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

Running clang-format with -style=file -i over attached C source file, with
attached .clang-format results in an extra line 2 being added and I cannot
understand the reason behind this addition.

-- 
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 35009] New: -Wtautological-constant-compare warning misleading on enum type

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35009

Bug ID: 35009
   Summary: -Wtautological-constant-compare warning misleading on
enum type
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: mattias.v.eriks...@ericsson.com
CC: llvm-bugs@lists.llvm.org

This program:

int foo() {
  enum E {a = 7} e = 1000;
  return e > 7;
}

Gives a warning when compiled with:

clang -Wtautological-constant-compare ee.c -S
ee.c:3:12: warning: comparison 'enum E' > 7 is always false
[-Wtautological-constant-compare]
  return e > 7;
 ~ ^ ~

The warning is a bit misleading because the comparison is only tautological
when e is assigned a value defined in the enum. Maybe it would make sense to
have the tautology check be on the enum's underlying type.

-- 
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 35010] New: Type punning in polly ACC

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35010

Bug ID: 35010
   Summary: Type punning in polly ACC
   Product: Polly
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Other
  Assignee: polly-...@googlegroups.com
  Reporter: philip.pfa...@gmail.com
CC: llvm-bugs@lists.llvm.org

In polly-acc, there is a dangerous case of type punning happening, which hasn't
blown up by pure chance.

GPUNodeBuilder is derived from IslNodeBuilder, and delegates generation of some
nodes back to its base. One of these cases is for handling `for` nodes. This
occurs whenever there's a loop within the kernel code. IslNodeBuilder will
decide whether this loops should be further parallelized through vectorization
or OMP, and to do so, it looks at the IslAstUserPayload attached to the nodes
annotation. This node, however, was generated by ppcg, which instead attaches
an `isl_ast_build` object to the node. The single reason why this doesn't blow
up is because IslNodeBuilder always looks at the `isInnermost` field first and
bails when that is true. By chance, this is always the case, because it's the
first field of the payload struct, and the first field of isl_ast_build is the
refcount.

-- 
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 10988] x86 MC encoder and disassembler bugs umbrella

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=10988
Bug 10988 depends on bug 7709, which changed state.

Bug 7709 Summary: [MC] Disassembler does not support x86 instruction prefixes
https://bugs.llvm.org/show_bug.cgi?id=7709

   What|Removed |Added

 Status|REOPENED|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 7709] [MC] Disassembler does not support x86 instruction prefixes

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=7709

Andrew V. Tischenko  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #10 from Andrew V. Tischenko  ---
Fixed with rL315899.

-- 
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 17697] [x86 disassembler] Wrong disassemble for some SSE2 instructions.

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=17697

Andrew V. Tischenko  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew V. Tischenko  ---
Fixed in rl315899

-- 
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 10988] x86 MC encoder and disassembler bugs umbrella

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=10988
Bug 10988 depends on bug 17697, which changed state.

Bug 17697 Summary: [x86 disassembler] Wrong disassemble for some SSE2 
instructions.
https://bugs.llvm.org/show_bug.cgi?id=17697

   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 10988] x86 MC encoder and disassembler bugs umbrella

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=10988
Bug 10988 depends on bug 19251, which changed state.

Bug 19251 Summary: [x86 disassembler] prefix ordering may ignore opsize and 
rep[n]e prefixes
https://bugs.llvm.org/show_bug.cgi?id=19251

   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 19251] [x86 disassembler] prefix ordering may ignore opsize and rep[n]e prefixes

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=19251

Andrew V. Tischenko  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew V. Tischenko  ---
Fixed in rL315899

-- 
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 10988] x86 MC encoder and disassembler bugs umbrella

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=10988
Bug 10988 depends on bug 32809, which changed state.

Bug 32809 Summary: [x86 disassembler] 'xchg' instruction uses two different 
sized register operands with data16 prefix
https://bugs.llvm.org/show_bug.cgi?id=32809

   What|Removed |Added

 Status|ASSIGNED|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 32809] [x86 disassembler] 'xchg' instruction uses two different sized register operands with data16 prefix

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32809

Andrew V. Tischenko  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew V. Tischenko  ---
Fixed rL315899

-- 
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 3704 in oss-fuzz: llvm/clang-proto-fuzzer: ASSERT: (isa(MaxNotTaken) || isa(MaxNotTaken)) && "No

2017-10-20 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,  v...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-10-20


New issue 3704 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm/clang-proto-fuzzer: ASSERT: (isa(MaxNotTaken) ||  
isa(MaxNotTaken)) && "No

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  (isa(MaxNotTaken) || isa(MaxNotTaken))  
&& "No

  llvm::ScalarEvolution::ExitLimit::ExitLimit
  llvm::ScalarEvolution::howManyLessThans

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710121744:201710130152


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


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] Issue 3705 in oss-fuzz: llvm/clang-fuzzer: ASSERT: getResultKind() == Found && "getFoundDecl called on non-unique result"

2017-10-20 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,  v...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-10-20


New issue 3705 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm/clang-fuzzer: ASSERT: getResultKind() == Found && "getFoundDecl called  
on non-unique result"

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  getResultKind() == Found && "getFoundDecl called on non-unique result"
  clang::Sema::ActOnTag
  clang::Parser::ParseClassSpecifier

Sanitizer: address (ASAN)

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


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 22947] Less efficient encoding using direct object emission

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=22947

Sean Eveson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||eveson.s...@gmail.com
 Resolution|--- |FIXED

--- Comment #3 from Sean Eveson  ---
This was fixed by r234249.

-- 
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 35011] New: Unable to parse main() when importing module interface

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35011

Bug ID: 35011
   Summary: Unable to parse main() when importing module interface
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: mferol...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Created attachment 19323
  --> https://bugs.llvm.org/attachment.cgi?id=19323&action=edit
Clang's reproducible crash files

Clang crashes when trying to compile a simple translation unit containing an
`import` statement.

How to reproduce:

$ cat math.mxx
#include 

export module math;

export namespace math
{
  template 
decltype(auto) sum(Ts && ...values)
{
  return (std::forward(values) + ... + 0);
}
}

$ cat main.cpp
import math;

int main()
{
  return math::sum(1, 2, 3);
}

$ clang++ -std=c++2a -fmodules-ts --precompile -x c++-module -o math.pcm
math.mxx
$ clang++ -std=c++2a -fmodules-ts -o math.pcm.o -c math.pcm
$ clang++ -std=c++2a -fmodules-ts -fmodule-file=math.pcm main.cpp

Crash log: https://p.iotek.org/z17

-- 
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 35012] New: Deleted template inline friend function in template class causes redefinition error

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35012

Bug ID: 35012
   Summary: Deleted template inline friend function in template
class causes redefinition error
   Product: clang
   Version: 5.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: s...@quanttec.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

When compiling the following code with `clang++ -std=c++17 Test.cpp`

  template 
  struct Test {
template 
friend bool operator==(Test, U) = delete;
  };
  Test test;

I get the following unexpected error:

  > clang++ -std=c++17 Test.cpp 
  Test.cpp:4:15: error: redefinition of 'operator=='
friend bool operator==(Test, U) = delete;
^
  Test.cpp:6:11: note: in instantiation of template class 'Test' requested
here
  Test test;
^
  Test.cpp:4:15: note: previous definition is here
friend bool operator==(Test, U) = delete;
  ^
  1 error generated.

GCC 7.2 produces no error.

-- 
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 35013] New: [openmp][debug] Instructions.h: Assertion "Both operands to ICmp instruction are not of the same type!"' failed.

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35013

Bug ID: 35013
   Summary: [openmp][debug] Instructions.h: Assertion "Both
operands to ICmp instruction are not of the same
type!"' failed.
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sergey.neste...@intel.com
CC: llvm-bugs@lists.llvm.org

my.c
void foo (int n, int *a)
{
int (* p)[n] = &a;

#pragma omp parallel
if (p == &a) {}
}

$ clang -v
clang version 6.0.0 (trunk 316219)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...



$ clang -c -O0 -g -fopenmp my.c -w
clang-6.0: .../llvm/include/llvm/IR/Instructions.h:1113: void
llvm::ICmpInst::AssertOK(): Assertion `getOperand(0)->getType() ==
getOperand(1)->getType() && "Both operands to ICmp instruction are not of the
same type!"' failed.
#0 0x04025a7b llvm::sys::PrintStackTrace(llvm::raw_ostream&)
.../llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x04025b0c PrintStackTraceSignalHandler(void*)
.../llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x04023ff8 llvm::sys::RunSignalHandlers()
.../llvm/lib/Support/Signals.cpp:49:0
#3 0x04025413 SignalHandler(int)
.../llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x7f8863a875e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0)
#5 0x7f886267e1f7 __GI_raise (/lib64/libc.so.6+0x351f7)
#6 0x7f886267f8e8 __GI_abort (/lib64/libc.so.6+0x368e8)
#7 0x7f8862677266 __assert_fail_base (/lib64/libc.so.6+0x2e266)
#8 0x7f8862677312 (/lib64/libc.so.6+0x2e312)
#9 0x02403a0c llvm::ICmpInst::AssertOK()
.../llvm/include/llvm/IR/Instructions.h:1115:0
#10 0x02403af5 llvm::ICmpInst::ICmpInst(llvm::CmpInst::Predicate,
llvm::Value*, llvm::Value*, llvm::Twine const&)
.../llvm/include/llvm/IR/Instructions.h:1169:0
#11 0x043444ea llvm::IRBuilder::CreateICmp(llvm::CmpInst::Predicate,
llvm::Value*, llvm::Value*, llvm::Twine const&)
.../llvm/include/llvm/IR/IRBuilder.h:1639:0
#12 0x0464cbb8 (anonymous
namespace)::ScalarExprEmitter::EmitCompare(clang::BinaryOperator const*,
llvm::CmpInst::Predicate, llvm::CmpInst::Predicate, llvm::CmpInst::Predicate)
.../llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:3246:0
#13 0x0463f982 (anonymous
namespace)::ScalarExprEmitter::VisitBinEQ(clang::BinaryOperator const*)
.../llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:729:0
#14 0x046513bc clang::StmtVisitorBase::Visit(clang::Stmt*)
.../llvm/tools/clang/include/clang/AST/StmtVisitor.h:63:0
#15 0x0463dafe (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
.../llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:358:0
#16 0x0464fe20
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
.../llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:3840:0
#17 0x045f5ac9
clang::CodeGen::CodeGenFunction::EvaluateExprAsBool(clang::Expr const*)
.../llvm/tools/clang/lib/CodeGen/CGExpr.cpp:150:0
#18 0x043a7a97
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr const*,
llvm::BasicBlock*, llvm::BasicBlock*, unsigned long)
.../llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:1650:0
#19 0x04335141
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&)
.../llvm/tools/clang/lib/CodeGen/CGStmt.cpp:640:0
#20 0x0433340e clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt
const*, llvm::ArrayRef)
.../llvm/tools/clang/lib/CodeGen/CGStmt.cpp:134:0
#21 0x04356026 operator()
.../llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp:1173:0
#22 0x04356026
clang::CodeGen::CodeGenFunction::EmitOMPParallelDirective(clang::OMPParallelDirective
const&)::{lambda(clang::CodeGen::CodeGenFunction&,
clang::CodeGen::PrePostActionTy&)#1}::operator()(clang::CodeGen::CodeGenFunction&,
clang::CodeGen::PrePostActionTy&) const
(.../debug_build/bin/clang-6.0+0x4356026)
#23 0x0436afc9 void
clang::CodeGen::RegionCodeGenTy::CallbackFn(long, clang::CodeGen::CodeGenFunction&,
clang::CodeGen::PrePostActionTy&)
.../llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.h:75:0
#24 0x046b4b95
clang::CodeGen::RegionCodeGenTy::operator()(clang::CodeGen::CodeGenFunction&)
const .../llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:717:0
#25 0x046b8b52 (anonymous
namespace)::CGOpenMPRegionInfo::EmitBody(clang::CodeGen::CodeGenFunction&,
clang::Stmt const*) .../llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:1141:0
#26 0x043513ff
clang::CodeGen::CodeGenFunction::GenerateOpenMPCapturedStmtFunction(clang::CapturedStmt
const&) .../llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp:485:0
#27 0x046b9e38
emitParallelOrTeamsOutlinedFunction(clang::CodeGen::CodeGenModu

[llvm-bugs] Issue 3704 in oss-fuzz: llvm/clang-proto-fuzzer: ASSERT: (isa(MaxNotTaken) || isa(MaxNotTaken)) && "No

2017-10-20 Thread k… via monorail via llvm-bugs 

Updates:
Cc: san...@google.com

Comment #2 on issue 3704 by k...@google.com: llvm/clang-proto-fuzzer:  
ASSERT: (isa(MaxNotTaken) ||  
isa(MaxNotTaken)) && "No

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

Probably a recent regression.


void foo(int *a) {
  if (a[4])
a[0];
  a[0] = 0;
  while (a[0] <= 1)
a[0] = (a[4] >= 0) + 1 + a[0];
}


clang -cc1 -triple x86_64-unknown-linux-gnu  -O2  -emit-obj z.c

llvm/lib/Analysis/ScalarEvolution.cpp:6570:  
llvm::ScalarEvolution::ExitLimit::ExitLimit(const llvm::SCEV *, const  
llvm::SCEV *, bool, ArrayRefllvm::SCEVPredicate *> *>): Assertion  
`(isa(MaxNotTaken) || isa(MaxNotTaken))  
&& "No point in having a non-constant max backedge taken count!"' failed.




--
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 34997] clang-cl: /showIncludes doesn't work with /EP

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34997

Erich Keane  changed:

   What|Removed |Added

 Status|ASSIGNED|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 33749] fatal error: error in backend: Cannot select: t195: i1 = add t192, t194 (in HexagonDAGToDAGISel::Select)

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=33749

Krzysztof Parzyszek  changed:

   What|Removed |Added

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

--- Comment #4 from Krzysztof Parzyszek  ---
Fixed in r316228. This commit required r315735, which wasn't yet started when
the bug was opened. This is why it took so long to fix it.

-- 
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 35014] New: Need a way to disable "warning: symbol scopes are not balanced in" for system libraries

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35014

Bug ID: 35014
   Summary: Need a way to disable "warning: symbol scopes are not
balanced in" for system libraries
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: COFF
  Assignee: unassignedb...@nondot.org
  Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org

If I build chromium with lld, virtually every link prints this:

[15895/50568] LINK(DLL) swiftshader/libGLESv2.dll swiftshader/libGLESv2.dll.lib
swiftshader/libGLESv2.dll.pdb
../../third_party/llvm-build/Release+Asserts/bin/lld-link: warning: symbol
scopes are not balanced in
f:\binaries\Intermediate\vctools\libconcrt.nativeproj__2086454777\objr\x86\InternalContextBase.obj
../../third_party/llvm-build/Release+Asserts/bin/lld-link: warning: symbol
scopes are not balanced in
f:\binaries\Intermediate\vctools\libconcrt.nativeproj__2086454777\objr\x86\InternalContextBase.obj
../../third_party/llvm-build/Release+Asserts/bin/lld-link: warning: symbol
scopes are not balanced in
f:\binaries\Intermediate\vctools\libconcrt.nativeproj__2086454777\objr\x86\ThreadScheduler.obj
../../third_party/llvm-build/Release+Asserts/bin/lld-link: warning: symbol
scopes are not balanced in
f:\binaries\Intermediate\vctools\libconcrt.nativeproj__2086454777\objr\x86\ThreadScheduler.obj
../../third_party/llvm-build/Release+Asserts/bin/lld-link: warning: symbol
scopes are not balanced in
f:\binaries\Intermediate\vctools\libconcrt.nativeproj__2086454777\objr\x86\ThreadScheduler.obj


This is not interesting and actionable for application developers (...unless
some flag we uses causes this?). So it shouldn't be printed.

Also, it'd be good if there was a way to consistently enable warnings-as-errors
for lld. In Chromium, our philosophy about warnings is in general "if it's an
interesting warning, it deserves to be made an error, else it shouldn't be
printed at all".

-- 
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 35015] New: Optimized code debug info: loop induction variable becomes constant

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35015

Bug ID: 35015
   Summary: Optimized code debug info: loop induction variable
becomes constant
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: DebugInfo
  Assignee: unassignedb...@nondot.org
  Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org

Here's an example where loop optimizations cause very misleading debug info:

use(int i);
static struct status {
  int value;
  unsigned char *p;
} status[32];
int init(void)
{
  int i;
  for (i = 0; i < 32; i++) {
status[i].value = 42;
use(i);
  }
}

clang -g -c test.i -o - -Oz | llvm-dwarfdump -name i -
0x009f: DW_TAG_variable [11]  
 DW_AT_location( 0x
0x0010 - 0x0032: consts +0,
stack-value )
 DW_AT_name( "i" )
 DW_AT_type( {0x006c} ( int ) )

The output of -print-after-all should give us a hint at which pass(es) are
dropping the llvm.dbg.value. Perhaps this is a use-case for
llvm::salvageDebugInfo().

-- 
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 35003] [X86] Help update_llc_test_checks.py recognise retl/retq to reduce CHECK duplication

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35003

Sanjay Patel  changed:

   What|Removed |Added

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

--- Comment #4 from Sanjay Patel  ---
https://reviews.llvm.org/rL316242

-- 
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 35016] New: suboptimal loop codegen?

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35016

Bug ID: 35016
   Summary: suboptimal loop codegen?
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: tras...@gmail.com
CC: llvm-bugs@lists.llvm.org

#include 
uint8_t data[32] = { 1,2,3,4 };
int main(int argc, const char* argv[])
{
int sum = 0;
for (int i=0; i < argc; ++i)
#if 0
sum += ((uint32_t*)data)[2 + i];
#else
sum += *(uint32_t*)&data[8 + i * 4];
#endif
return sum;
}

https://godbolt.org/g/sJTGjz

$ clang -c -Oz
main: # @main
  movsxd rcx, edi
  xor edx, edx
  push 8
  pop rsi
  xor eax, eax
  jmp .LBB0_1
.LBB0_3: # in Loop: Header=BB0_1 Depth=1
  movsxd rsi, esi
  add eax, dword ptr [rsi + data]
  inc rdx
  add esi, 4
.LBB0_1: # =>This Inner Loop Header: Depth=1
  cmp rdx, rcx
  jl .LBB0_3
  ret
data:
  .asciz
"\001\002\003\004\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"

$ g++ -c -Os
main:
  xor edx, edx
  xor eax, eax
.L3:
  cmp edi, edx
  jle .L1
  add eax, DWORD PTR data[8+rdx*4]
  inc rdx
  jmp .L3
.L1:
  ret
data:
  .byte 1
  .byte 2
  .byte 3
  .byte 4
  .zero 28

-- 
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 34192] [5.0] check-lldb-unit hangs with lldb-server running

2017-10-20 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34192

lab...@google.com changed:

   What|Removed |Added

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

--- Comment #8 from lab...@google.com ---
(In reply to labath from comment #7)
> (In reply to Jonas Hahnfeld from comment #6)
> > (In reply to labath from comment #5)
> > > I believe  will fix your problem, but I
> > > can't tell for sure (as things were working for me in the first place). If
> > > you have some time, I'd appreciate it if you can test it.
> > 
> > I think this works, but maybe for the wrong reasons: I build with the LLVM
> > tree with Clang 4.0.1 and therefore have LD_LIBRARY_PATH with libc++ set. So
> > it does not pick up the newly built library in /lib/...
> 
> The purpose of the test is not to test the newly-built libc++. We just need
> _any_ c++ library around to be able to run the inferior. So, we pick the c++
> library that you build the rest of your toolchain with, since that has to be
> around and working. In your case, we just happen to need LD_LIBRARY_PATH set
> in order to use c++ library that we build with.
> 
> So, unless I misunderstood something, I think this solution is fine.

I have committed r316244, which should fix this.

If the test still fails for you, or you think the fix is incorrect, let me
know.

-- 
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 3705 in oss-fuzz: llvm/clang-fuzzer: ASSERT: getResultKind() == Found && "getFoundDecl called on non-unique result"

2017-10-20 Thread richards… via monorail via llvm-bugs 


Comment #2 on issue 3705 by richardsm...@google.com: llvm/clang-fuzzer:  
ASSERT: getResultKind() == Found && "getFoundDecl called on non-unique  
result"

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

Slightly unreduced to:

struct { struct {} c; };
struct { struct {} c; };
struct c x;

--
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] Issue 3688 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty()

2017-10-20 Thread monor… via monorail via llvm-bugs 

Updates:
Labels: ClusterFuzz-Top-Crash

Comment #2 on issue 3688 by  
monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty()

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

Testcase 6748633157337088 is a top crash on ClusterFuzz for linux platform.  
Please prioritize fixing this crash.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 3710 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo

2017-10-20 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,  v...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-10-21


New issue 3710 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm/clang-fuzzer: Stack-overflow in  
clang::FunctionProtoType::getExtProtoInfo

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

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

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: 0x7fff25123d88
Crash State:
  clang::FunctionProtoType::getExtProtoInfo
  clang::FunctionProtoType::Profile
  llvm::ContextualFoldingSetclang::ASTContext&>::NodeEq


Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710200650:201710210105


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


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] Issue 3688 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty()

2017-10-20 Thread k… via monorail via llvm-bugs 

Updates:
Cc: vtsyrklev...@google.com

Comment #3 on issue 3688 by k...@google.com:  
llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty()

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

Vlad, please take a look.

--
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 35020] New: clang crashes at -O1 and above with -fexperimental-new-pass-manager: Assertion `!UR.InvalidatedSCCs.count(C) && "Processing an invalid SCC!"' failed

2017-10-20 Thread via llvm-bugs 
olly/llvm/include/llvm/IR/PassManagerInternal.h:81:0
#13 0x01ef2513 llvm::PassManager>::run(llvm::Module&,
llvm::AnalysisManager&)
/home/su/software/tmp/polly/llvm/include/llvm/IR/PassManager.h:460:0
#14 0x024d5885 (anonymous
namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction,
std::unique_ptr >)
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:977:0
#15 0x024d8405 ~unique_ptr /usr/include/c++/4.9/bits/unique_ptr.h:235:0
#16 0x024d8405 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 >)
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1143:0
#17 0x02cf596c ~unique_ptr /usr/include/c++/4.9/bits/unique_ptr.h:235:0
#18 0x02cf596c
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:294:0
#19 0x02ed257c swap /usr/include/c++/4.9/bits/move.h:177:0
#20 0x02ed257c clang::ParseAST(clang::Sema&, bool, bool)
/home/su/software/tmp/polly/llvm/tools/clang/lib/Parse/ParseAST.cpp:161:0
#21 0x02cf4e00 clang::CodeGenAction::ExecuteAction()
/home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:1032:0
#22 0x0289271e clang::FrontendAction::Execute()
/home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:897:0
#23 0x02866516
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:992:0
#24 0x02929b71
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/home/su/software/tmp/polly/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252:0
#25 0x00d83a58 cc1_main(llvm::ArrayRef, char const*,
void*)
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/cc1_main.cpp:221:0
#26 0x00d104c3 ExecuteCC1Tool
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:309:0
#27 0x00d104c3 main
/home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:388:0
#28 0x7fa95eb60f45 __libc_start_main
/build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:321:0
#29 0x00d7fc99 _start
(/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0xd7fc99)
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 -coverage-notes-file
/home/su/specres/20171020-clangpolly-m32-fexperimental-new-pass-manager-O3-build-055134/delta/small.gcno
-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
-w -fdebug-compilation-dir
/home/su/specres/20171020-clangpolly-m32-fexperimental-new-pass-manager-O3-build-055134/delta
-ferror-limit 19 -fmessage-length 116 -fexperimental-new-pass-manager
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x
c small.c 
1.   parser at end of file
2.  Optimizer
clang-6.0: error: unable to execute command: Aborted (core dumped)
clang-6.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 6.0.0 (http://llvm.org/git/clang.git
d6aede0fad127fa8eedd339e9594bf30cbd98294) (llvm/trunk 316219)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
clang-6.0: 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-6.0: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-6.0: note: diagnostic msg: /tmp/small-2893a4.c
clang-6.0: note: diagnostic msg: /tmp/small-2893a4.sh
clang-6.0: note: diagnostic msg: 


$ 


--


int a, b, c;

int fn1 (int);

static int fn2 ()
{
  fn1 (0);
  fn2 ();
  return b;
}

int fn1 (int f)
{
  int g = 0;
  for (; g < 4; g++)
g &= a > fn1 (0);
  fn2 ();
  return c;
}

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