[llvm-bugs] [Bug 37145] New: Assertion `SizeSoFar == Layout->getSizeInBytes() && "Layout of constant struct may be incorrect!"' failed.

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37145

Bug ID: 37145
   Summary: Assertion `SizeSoFar == Layout->getSizeInBytes() &&
"Layout of constant struct may be incorrect!"' failed.
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: shlei...@gmail.com
CC: llvm-bugs@lists.llvm.org

$ clang-trunk -v
clang version 7.0.0 (trunk 328089)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

$ clang-trunk abc.c
clang-7.0:
/home/suhua/compilers/trunk/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:2278:
void emitGlobalConstantStruct(const llvm::DataLayout&, const
llvm::ConstantStruct*, llvm::AsmPrinter&, const llvm::Constant*, uint64_t):
Assertion `SizeSoFar == Layout->getSizeInBytes() && "Layout of constant struct
may be incorrect!"' failed.
#0 0x0234769a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x234769a)
#1 0x0234570e llvm::sys::RunSignalHandlers()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x234570e)
#2 0x02345872 SignalHandler(int)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2345872)
#3 0x7fa4eee7a390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7fa4edbea428 gsignal
/build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7fa4edbec02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
#6 0x7fa4edbe2bd7 __assert_fail_base
/build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
#7 0x7fa4edbe2c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x02ab173b emitGlobalConstantImpl(llvm::DataLayout const&,
llvm::Constant const*, llvm::AsmPrinter&, llvm::Constant const*, unsigned long)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2ab173b)
#9 0x02ab20b6 llvm::AsmPrinter::EmitGlobalVariable(llvm::GlobalVariable
const*) (/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2ab20b6)
#10 0x02aafb64 llvm::AsmPrinter::doFinalization(llvm::Module&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2aafb64)
#11 0x01ea541b llvm::FPPassManager::doFinalization(llvm::Module&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1ea541b)
#12 0x01eb04f7 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1eb04f7)
#13 0x024e9626 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x24e9626)
#14 0x024eb4f3 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/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x24eb4f3)
#15 0x02d4787b
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2d4787b)
#16 0x03246142 clang::ParseAST(clang::Sema&, bool, bool)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x3246142)
#17 0x02d46ebf clang::CodeGenAction::ExecuteAction()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2d46ebf)
#18 0x028d5816 clang::FrontendAction::Execute()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x28d5816)
#19 0x028aad5e
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x28aad5e)
#20 0x0296912e
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x296912e)
#21 0x00c9b1c8 cc1_main(llvm::ArrayRef, char const*,
void*) (/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc9b1c8)
#22 0x00c1eefd main
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc1eefd)
#23 0x7fa4edbd5830 __libc_start_main
/build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:325:0
#24 0x00c95e79 _start
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc95e79)
Stack dump:
0.  Program arguments: /home/suhua/compilers/trunk/root-clang/bin/clang-7.0
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name abc.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 -resource-dir
/home/suhua/compilers/trunk/root-clang/lib/clang/7.0.0 -c-isystem . -c-isystem
/usr/local/include/csmith-2.3.0/

[llvm-bugs] [Bug 36430] Crash after 'breakpoint delete' and 'process continue'

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36430

Eugene Zemtsov  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] 3 issues changed in oss-fuzz

2018-04-16 Thread aa… via monorail via llvm-bugs 

Updates:
Status: WontFix

Comment by aa...@google.com:
We are closing all ooms and timeouts that are unreproducible. We won't be  
filing such bugs in future.


Affected issues:
  issue 5580: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in  
llvm_llvm-isel-fuzzer--x86_64-O2

http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5580

  issue 6772: llvm/llvm-opt-fuzzer--x86_64-indvars: Timeout in  
llvm_llvm-opt-fuzzer--x86_64-indvars

http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6772

  issue 7627: llvm/llvm-special-case-list-fuzzer: NULL
http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7627



--
You received this message because you are listed in the owner
or CC fields of these issues, or because you starred them.
You may adjust your issue notification preferences at:
http://bugs.chromium.org/hosting/settings

___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] 5 issues changed in oss-fuzz

2018-04-16 Thread aa… via monorail via llvm-bugs 

Updates:
Status: WontFix

Comment by aa...@google.com:
We are closing all ooms and timeouts that are unreproducible. We won't be  
filing such bugs in future.


Affected issues:
  issue 3495: llvm: Timeout in llvm_clang-format-fuzzer
http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3495

  issue 3827: llvm/llvm-demangle-fuzzer: Timeout in  
llvm_llvm-demangle-fuzzer

http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3827

  issue 4077: llvm/llvm-demangle-fuzzer: NULL
http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4077

  issue 4084: llvm/llvm-special-case-list-fuzzer: Timeout in  
llvm_llvm-special-case-list-fuzzer

http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4084

  issue 4815: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer
http://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4815



--
You received this message because you are listed in the owner
or CC fields of these issues, or because you starred them.
You may adjust your issue notification preferences at:
http://bugs.chromium.org/hosting/settings

___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36991] LLD-linked binary segfaults at runtime on alpine linux

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36991

Reid Kleckner  changed:

   What|Removed |Added

 CC||r...@google.com
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #10 from Reid Kleckner  ---
This was reverted in r330164, since it caused many Chromium test binaries to
crash on exit.

-- 
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 37144] New: Codegen creates an extra bench in a binary search

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37144

Bug ID: 37144
   Summary: Codegen creates an extra bench in a binary search
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: raf...@espindo.la
CC: llvm-bugs@lists.llvm.org, r...@google.com

lld has a binary search function written as:

--
  while (Size != 1) {
size_t H = Size / 2;
const It MI = First + H;
Size -= H;
First = Comp(Value, *MI) ? First : First + H;
  }
  return Comp(Value, *First) ? First : First + 1;
--

The objective is to avoid branch misprediction. The body has no branches and
the loop has no early exits, so it is very predictable.

Everything is fine in the IR. The loop is a single BB and a select is used:

%12 = phi i32* [ %0, %8 ], [ %19, %10 ]
...
%14 = getelementptr inbounds i32, i32* %12, i64 %13
...
%18 = icmp ugt i64 %17, %2
%19 = select i1 %18, i32* %12, i32* %14

But codegen decides to use branches:

cmpq%rdx, %rcx
ja  .LBB81_4
# %bb.3:#   in Loop: Header=BB81_2 Depth=1
leaq(%rdi,%rax,4), %rdi
.LBB81_4:   #   in Loop: Header=BB81_2 Depth=1
cmpq$1, %rsi
jne .LBB81_2


Which causes massive amounts of branch misprediction. LLD's largest allocation
is a hash table that exists just to avoid using the binary search as often
since it is so expensive.

GCC gets this right. In a lld version without the extra hash table it looks
like fixing this bug would result in a 12% speedup of the entire link is some
testcases.

-- 
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 37033] [m32][debug] FE fails with "LHS is a reference type?" assertion on "va_end" builtins redeclaration

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37033

Erich Keane  changed:

   What|Removed |Added

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

--- Comment #3 from Erich Keane  ---
After review, we've decided to prevent overloading of a bunch of builtins (see
330160).  You'll now get a new error for each of these, but at least it won't
crash :)

-- 
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 37143] New: 16-bit loads produce incorrect code on AVR

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37143

Bug ID: 37143
   Summary: 16-bit loads produce incorrect code on AVR
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: AVR
  Assignee: unassignedb...@nondot.org
  Reporter: keshav.k...@gmail.com
CC: llvm-bugs@lists.llvm.org

Here is a .ll file:

  target triple = "avr-atmel-none"

  define void @foo(i16* %x) {
  entry:
%0 = load i16, i16* %x
%neg = xor i16 %0, -1
store i16 %neg, i16* %x
ret void
  }

llc from trunk today, with no command line options, compiles it to the
following assembly code (after removing comments and directives):

  foo:
mov r30, r24
mov r31, r25
ld  r24, Z+
ld  r25, Z
com r24
com r25
st  Z, r24
std Z+1, r25
ret

I believe this is incorrect.  When loading %x from Z+1:Z into r25:r24,
Z is incremented, and it is not decremented again before storing the
complemented r25:r24 back into memory at Z+1:Z.  Therefore the program
writes to a pair of memory locations which are off by one from where
it should be writing.

Here's an altered assembly listing which corrects the issue:

  foo:
mov  r30, r24
mov  r31, r25
ld   r24, Z
ldd  r25, Z+1
com  r24
com  r25
st   Z, r24
std  Z+1, r25
ret

By the way, are LDD and STD part of the core set of instructions which
all AVR devices must support?  (I assumed that since I didn't pass
"-mcpu" to llc, its instruction selection would be limited to that
core instruction set.)  The AVR ISA manual says "Not all variants of
this instruction is available in all devices. Refer to the device
specific instruction set summary." in the sections for the LD X, LD(D)
Y, LD(D) Z, ST X, ST(D) Y, and ST(D) Z instructions; but I wasn't able
to find out whether any of the variants *are* guaranteed to be
available in all devices.

Of course, even when LDD and STD are supported on a given device, it
may be advantageous not to use them since on some devices they take
more cycles to execute than other load/store variants, if I'm not
mistaken.

About the title of this bug -- I don't really know anything about the
internals of LLVM, but I notice that in
:/lib/Target/AVR/AVRInstrInfo.td , the definitions of STPtrPiRr,
STWPtrPiRr, STPtrPdRr, and STWPtrPdRr contain references to
"post_store" and "pre_store", while the corresponding definitions
LDRdPtrPi, LDWRdPtrPi, LDRdPtrPd, and LDWRdPtrPd don't seem to have
any similar references, so I've somewhat arbitrarily blamed the load
for causing the problem.  Maybe the problem is somewhere else
entirely, though.

Thanks,
Keshav

-- 
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 37142] New: UBSan failure (signed integer overflow) in clang::ento::ElementRegion::getAsArrayOffset()

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37142

Bug ID: 37142
   Summary: UBSan failure (signed integer overflow) in
clang::ento::ElementRegion::getAsArrayOffset()
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: ale...@google.com
CC: llvm-bugs@lists.llvm.org

$ cat test-ElementRegion__getAsArrayOffset.cc
void c(long long *d) {
  long e, f;
  e = f = d[1];
  for (; d[e];) f-- > 0;
}
$ ./clang-tidy -checks=-*,clang-analyzer*
test-ElementRegion__getAsArrayOffset.cc -- -std=c++11
include/clang/AST/CharUnits.h:143:35: runtime error: signed integer overflow: 8
* -9223372036854775808 cannot be represented in type 'long'
#0 in operator* include/clang/AST/CharUnits.h:143:35
#1 in operator* include/clang/AST/CharUnits.h:210
#2 in clang::ento::ElementRegion::getAsArrayOffset() const
lib/StaticAnalyzer/Core/MemRegion.cpp:1253
#3 in (anonymous
namespace)::RegionStoreManager::getBindingForElement((anonymous
namespace)::RegionBindingsRef const&, clang::ento::ElementRegion const*)
lib/StaticAnalyzer/Core/RegionStore.cpp:1644:33
#4 in (anonymous namespace)::RegionStoreManager::getBinding((anonymous
namespace)::RegionBindingsRef const&, clang::ento::Loc, clang::QualType)
lib/StaticAnalyzer/Core/RegionStore.cpp:1457:29
#5 in (anonymous namespace)::RegionStoreManager::getBinding(void const*,
clang::ento::Loc, clang::QualType)
lib/StaticAnalyzer/Core/RegionStore.cpp:509:12
#6 in getRawSVal
include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h:770:38
#7 in clang::ento::ProgramState::getSVal(clang::ento::Loc, clang::QualType)
const lib/StaticAnalyzer/Core/ProgramState.cpp:258
#8 in
clang::ento::ExprEngine::evalLoadCommon(clang::ento::ExplodedNodeSet&,
clang::Expr const*, clang::Expr const*, clang::ento::ExplodedNode*,
llvm::IntrusiveRefCntPtr, clang::ento::SVal, clang::ProgramPointTag const*,
clang::QualType) lib/StaticAnalyzer/Core/ExprEngine.cpp:2967:18
#9 in clang::ento::ExprEngine::evalLoad(clang::ento::ExplodedNodeSet&,
clang::Expr const*, clang::Expr const*, clang::ento::ExplodedNode*,
llvm::IntrusiveRefCntPtr, clang::ento::SVal, clang::ProgramPointTag const*, clang::QualType)
lib/StaticAnalyzer/Core/ExprEngine.cpp:2935:3
#10 in clang::ento::ExprEngine::VisitCast(clang::CastExpr const*,
clang::Expr const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
lib/StaticAnalyzer/Core/ExprEngineC.cpp:300:7
#11 in clang::ento::ExprEngine::Visit(clang::Stmt const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
lib/StaticAnalyzer/Core/ExprEngine.cpp:1756:7
#12 in clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*,
clang::ento::ExplodedNode*) lib/StaticAnalyzer/Core/ExprEngine.cpp:868:5
#13 in clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*)
lib/StaticAnalyzer/Core/ExprEngine.cpp:698:7
#14 in clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*,
unsigned int, clang::ento::ExplodedNode*)
lib/StaticAnalyzer/Core/CoreEngine.cpp:433:12
#15 in
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&)
lib/StaticAnalyzer/Core/CoreEngine.cpp:191:7
#16 in clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext
const*, unsigned int, llvm::IntrusiveRefCntPtr) lib/StaticAnalyzer/Core/CoreEngine.cpp:147:5
#17 in ExecuteWorkList
include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:168:19
#18 in (anonymous
namespace)::AnalysisConsumer::ActionExprEngine(clang::Decl*, bool,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*) lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:748
#19 in (anonymous namespace)::AnalysisConsumer::HandleCode(clang::Decl*,
unsigned int, clang::ento::ExprEngine::InliningModes,
llvm::DenseSet >*) lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
#20 in HandleDeclsCallGraph
lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:506:5
#21 in runAnalysisOnTranslationUnit
lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:553

-- 
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 36971] debian sid/amd64 packages for trunk are stale

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36971

Sylvestre Ledru  changed:

   What|Removed |Added

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

--- Comment #3 from Sylvestre Ledru  ---
 sid (unstable) - Last update : Thu, 12 Apr 2018 01:05:19 UTC / Revision:
329847 

only 4 days, please don't reopen bugs for such short period...
here, it was because failing tests.

-- 
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 36971] debian sid/amd64 packages for trunk are stale

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36971

Roman Lebedev  changed:

   What|Removed |Added

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

--- Comment #2 from Roman Lebedev  ---
And back

-- 
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 37141] New: Virus! \llvm\test\tools\llvm-readobj\Inputs\coff-no-load-config.exe.

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37141

Bug ID: 37141
   Summary: Virus!
\llvm\test\tools\llvm-readobj\Inputs\coff-no-load-conf
ig.exe.
   Product: new-bugs
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: coder0...@gmail.com
CC: llvm-bugs@lists.llvm.org

McAfee antivirus is flagging this file as Artemis!E5F241606A26 and consitently
deleting 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] Issue 5580 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in llvm_llvm-isel-fuzzer--x86_64-O2

2018-04-16 Thread sheriff… via monorail via llvm-bugs 

Updates:
Labels: Deadline-Approaching

Comment #2 on issue 5580 by sheriff...@chromium.org:  
llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in  
llvm_llvm-isel-fuzzer--x86_64-O2

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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 5614 in oss-fuzz: llvm/clang-fuzzer: ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset && NextLocalOffset + TokLength

2018-04-16 Thread sheriff… via monorail via llvm-bugs 

Updates:
Labels: Deadline-Approaching

Comment #2 on issue 5614 by sheriff...@chromium.org: llvm/clang-fuzzer:  
ASSERT: NextLocalOffset + TokLength + 1 > NextLocalOffset &&  
NextLocalOffset + TokLength

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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 5579 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: DAG.getTargetLoweringInfo().isTypeLegal(PartVT) && "Copying to an illegal type!"

2018-04-16 Thread sheriff… via monorail via llvm-bugs 

Updates:
Labels: Deadline-Approaching

Comment #2 on issue 5579 by sheriff...@chromium.org:  
llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT:  
DAG.getTargetLoweringInfo().isTypeLegal(PartVT) && "Copying to an illegal  
type!"

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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 5537 in oss-fuzz: llvm/clang-proto-fuzzer: ASSERT: isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant

2018-04-16 Thread sheriff… via monorail via llvm-bugs 

Updates:
Labels: Deadline-Approaching

Comment #4 on issue 5537 by sheriff...@chromium.org:  
llvm/clang-proto-fuzzer: ASSERT: isLoopInvariant(Operands[i], L)  
&& "SCEVAddRecExpr operand is not loop-invariant

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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 37140] New: _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37140

Bug ID: 37140
   Summary: _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not
implemented
   Product: clang
   Version: 6.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: christophe.j.he...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Both intrinsics are not to be found within avx512fintrin.h.
Only the mullo_epi64 versions see to be implemented, but require AVX512DQ.
Sadly, I compile for a Xeon Phi KNL / KNM.

-- 
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 37139] New: Crash in clang::ento::ExprEngine::getRegionForConstructedObject

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37139

Bug ID: 37139
   Summary: Crash in
clang::ento::ExprEngine::getRegionForConstructedObject
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: ale...@google.com
CC: llvm-bugs@lists.llvm.org

$ cat test-clang__ento__ExprEngine__getRegionForConstructedObject.cc
class a {};
struct b {
  long c;
  const a 
};
void fn1() { b e{0, a()}; }
$ ./clang-tidy -checks=-*,clang-analyzer-core*
test-clang__ento__ExprEngine__getRegionForConstructedObject.cc -- -std=c++11
assert.h assertion failed at
tools/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp:187 in const
clang::ento::MemRegion
*clang::ento::ExprEngine::getRegionForConstructedObject(const
clang::CXXConstructExpr *, clang::ento::ExplodedNode *, const
clang::ConstructionContext *, clang::ento::ExprEngine::EvalCallOptions &):
VD->getType()->isReferenceType()
@ 0x564ea13a63f6  __assert_fail
@ 0x564e9f18c2e9 
clang::ento::ExprEngine::getRegionForConstructedObject()
@ 0x564e9f18c6e2  clang::ento::ExprEngine::VisitCXXConstructExpr()
@ 0x564e9f15d5c7  clang::ento::ExprEngine::Visit()
@ 0x564e9f159fae  clang::ento::ExprEngine::ProcessStmt()
@ 0x564e9f159ccb  clang::ento::ExprEngine::processCFGElement()
@ 0x564e9f17f155  clang::ento::CoreEngine::HandlePostStmt()
@ 0x564e9f17e40d  clang::ento::CoreEngine::ExecuteWorkList()
@ 0x564e9eeac20c  (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x564e9eeabd86  (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x564e9ee97af4  (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@ 0x564e9f43fb5c  clang::MultiplexConsumer::HandleTranslationUnit()
@ 0x564e9f5e13a4  clang::ParseAST()
@ 0x564e9f439013  clang::FrontendAction::Execute()
@ 0x564e9f2db381  clang::CompilerInstance::ExecuteAction()
@ 0x564e9f1e2411 
clang::tooling::FrontendActionFactory::runInvocation()
@ 0x564e9f1e217a  clang::tooling::ToolInvocation::runInvocation()
@ 0x564e9f1e1946  clang::tooling::ToolInvocation::run()
@ 0x564e9f1e40c3  clang::tooling::ClangTool::run()
@ 0x564e9eb4e88f  clang::tidy::runClangTidy()

-- 
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 36356] [AMDGPU][MC] v_cndmask_b32 disassembly failures

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36356

Dmitry  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Fixed By Commit(s)||330123
 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 37138] New: msan: incorrect origin for 64-bit values

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37138

Bug ID: 37138
   Summary: msan: incorrect origin for 64-bit values
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: compiler-rt
  Assignee: unassignedb...@nondot.org
  Reporter: dvyu...@google.com
CC: llvm-bugs@lists.llvm.org

clang version 7.0.0 (trunk 326052)


#include 

__attribute__((noinline)) void inithalf(void* x)
{
*(int*)x = 0;
}

__attribute__((noinline)) void copyhalf(void* x, void* y)
{
*(int*)x = *(int*)y;
}

__attribute__((noinline)) void copy(long long* x, long long* y)
{
*x = *y;
}

int main() {
long long x, y, z;
copyhalf(, );
inithalf();
copy(, );
if (x)
exit(1);
}

==258685==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x499df4 in main /tmp/msan.c:23:6

#1 0x7f00b44cb2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#2 0x41d639 in _start
(/usr/local/google/home/dvyukov/src/linux2/a.out+0x41d639)

  Uninitialized value was stored to memory at
#0 0x499c98 in copy /tmp/msan.c:15:5

  Uninitialized value was stored to memory at
#0 0x499c03 in copyhalf /tmp/msan.c:10:11

  Uninitialized value was created by an allocation of 'z' in the stack frame of
function 'main'
#0 0x499cd0 in main /tmp/msan.c:18

SUMMARY: MemorySanitizer: use-of-uninitialized-value /tmp/msan.c:23:6 in main

Uninit value comes from 'y'.

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

[llvm-bugs] [Bug 37137] New: Clang-cl prevents `__restrict`ed struct members to show in debugger

2018-04-16 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=37137

Bug ID: 37137
   Summary: Clang-cl prevents `__restrict`ed struct members to
show in debugger
   Product: new-bugs
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: antoine.vugli...@free.fr
CC: llvm-bugs@lists.llvm.org

When compiling with clang-cl and debugging info activated (/Zi), Visual
Studio's debugger is unable to access struct/class members that are marked with
`__restrict`. This however works with cl.exe.

Example:

```
struct Foo
{
int * __restrict i;
};

int main(int argc, char** argv)
{
Foo foo;

return 0;
}
```

Compiling this code in debug and trying to visualize the value of `i` (either
from hovering it in the source pane or by the watch window) will only show
`` or `class "Foo" has no member "i"`.
Removing the attribute will allow the debugger to inspect `foo.i`.

OS: Windows 10, Windows 7
VS: 2015U3
target: windows x86 and x64

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