date:20180226

[llvm-bugs] [Bug 36529] MemorySSA doesn't properly invalidate def-def cache entries

2018-02-26 Thread via llvm-bugs

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

George Burgess  changed:

   What|Removed |Added

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

--- Comment #2 from George Burgess  ---
Oh, right. VHes are things.

In general, I'm a bit uneasy about the idea that we just hold on to this cache
entry without any way to update/detect it from the cached value, but I can't
think of a concrete example (that isn't a misoptimization) that would cause a
WeakVH approach to break here.

That said, should we find such an example in the future, we can always try to
make that work.

r326175 + r326177 should fix this.

Thank you!

-- 
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 36531] New: Assertion `TypeSize == Context.getTypeSize(Context.CharTy) && "Unhandled vector element size in vector compare"' failed.

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36531
   Summary: Assertion `TypeSize ==
Context.getTypeSize(Context.CharTy) && "Unhandled
vector element size in vector compare"' 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 326083)
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/tools/clang/lib/Sema/SemaExpr.cpp:10124:
clang::QualType clang::Sema::GetSignedVectorType(clang::QualType): Assertion
`TypeSize == Context.getTypeSize(Context.CharTy) && "Unhandled vector element
size in vector compare"' failed.
#0 0x0232082a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x232082a)
#1 0x0231e89e llvm::sys::RunSignalHandlers()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x231e89e)
#2 0x0231ea02 SignalHandler(int)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x231ea02)
#3 0x7f3db2892390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f3db15fd428 gsignal
/build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f3db15ff02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f3db15f5bd7 __assert_fail_base
/build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
#7 0x7f3db15f5c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x032b7ab5
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32b7ab5)
#9 0x032dcebd
clang::Sema::CheckVectorCompareOperands(clang::ActionResult&, clang::ActionResult&, clang::SourceLocation,
clang::BinaryOperatorKind)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32dcebd)
#10 0x032dff84
clang::Sema::CheckCompareOperands(clang::ActionResult&,
clang::ActionResult&, clang::SourceLocation,
clang::BinaryOperatorKind, bool)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32dff84)
#11 0x032e29e2 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation,
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32e29e2)
#12 0x032e3537 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32e3537)
#13 0x032e3af6 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x32e3af6)
#14 0x02f6f36c
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f6f36c)
#15 0x02f6efac
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f6efac)
#16 0x02f4047f
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f4047f)
#17 0x02f5154e clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f5154e)
#18 0x02f54714
clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool,
clang::Parser::ForRangeInit*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f54714)
#19 0x02f549cd
clang::Parser::ParseDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f549cd)
#20 0x02fa8528
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2fa8528)
#21 0x02fa867e
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2fa867e)
#22 0x02fab7af clang::Parser::ParseCompoundStatementBody(bool)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2fab7af)
#23 0x02fad53f

[llvm-bugs] [Bug 36530] New: Assertion `Subtarget.hasAVX2() && "256-bit insert/extract only available in AVX2"' failed.

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36530
   Summary: Assertion `Subtarget.hasAVX2() && "256-bit
insert/extract only available in AVX2"' failed.
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: shlei...@gmail.com
CC: llvm-bugs@lists.llvm.org

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

$ clang-trunk -O3 abc.c
clang-7.0:
/home/suhua/compilers/trunk/llvm/lib/Target/X86/X86InstrInfo.cpp:10292: virtual
void llvm::X86InstrInfo::setExecutionDomain(llvm::MachineInstr&, unsigned int)
const: Assertion `Subtarget.hasAVX2() && "256-bit insert/extract only available
in AVX2"' failed.
#0 0x0232082a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x232082a)
#1 0x0231e89e llvm::sys::RunSignalHandlers()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x231e89e)
#2 0x0231ea02 SignalHandler(int)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x231ea02)
#3 0x7f16c601a390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f16c4d85428 gsignal
/build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f16c4d8702a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f16c4d7dbd7 __assert_fail_base
/build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
#7 0x7f16c4d7dc82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x017f70da
llvm::X86InstrInfo::setExecutionDomain(llvm::MachineInstr&, unsigned int) const
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x17f70da)
#9 0x01ac9172 llvm::ExecutionDomainFix::collapse(llvm::DomainValue*,
unsigned int) (/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1ac9172)
#10 0x01ac9294 llvm::ExecutionDomainFix::release(llvm::DomainValue*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1ac9294)
#11 0x01acb881
llvm::ExecutionDomainFix::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.266] (/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1acb881)
#12 0x01acbe23
llvm::ExecutionDomainFix::runOnMachineFunction(llvm::MachineFunction&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1acbe23)
#13 0x01b68825
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1b68825)
#14 0x01e8e163 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1e8e163)
#15 0x01e8e20c llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1e8e20c)
#16 0x01e8eaaf llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x1e8eaaf)
#17 0x024c4b36 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x24c4b36)
#18 0x024c69fb 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+0x24c69fb)
#19 0x02d03bfb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2d03bfb)
#20 0x02f2d272 clang::ParseAST(clang::Sema&, bool, bool)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2f2d272)
#21 0x02d0323f clang::CodeGenAction::ExecuteAction()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2d0323f)
#22 0x02896216 clang::FrontendAction::Execute()
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x2896216)
#23 0x0286b61e
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x286b61e)
#24 0x0292a972
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0x292a972)
#25 0x00c8f268 cc1_main(llvm::ArrayRef, char const*,
void*) (/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc8f268)
#26 0x00c13b71 main
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc13b71)
#27 0x7f16c4d70830 __libc_start_main
/build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:325:0
#28 0x00c89f19 _start
(/home/suhua/compilers/trunk/root-clang/bin/clang-7.0+0xc89f19)
Stack dump:
0.  Program

[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers

2018-02-26 Thread via llvm-bugs

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

Bug 36521 Summary: clang crashes on passing a coro param to operator new
https://bugs.llvm.org/show_bug.cgi?id=36521

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |LATER

-- 
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 36521] clang crashes on passing a coro param to operator new

2018-02-26 Thread via llvm-bugs

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

Andrew Kelley  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||h...@chromium.org
 Resolution|--- |LATER

--- Comment #6 from Andrew Kelley  ---
Alright, closing for real this time.

I'm going to work around the issue in the frontend, and I'll remove the
workaround in llvm 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 36206] UBSan failure (signed integer overflow) in NonnullGlobalConstantsChecker

2018-02-26 Thread via llvm-bugs

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

George Karpenkov  changed:

   What|Removed |Added

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

--- Comment #5 from George Karpenkov  ---
Hopefully fixed 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 36529] New: MemorySSA doesn't properly invalidate def-def cache entries

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36529
   Summary: MemorySSA doesn't properly invalidate def-def cache
entries
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Global Analyses
  Assignee: unassignedb...@nondot.org
  Reporter: george.burgess...@gmail.com
CC: llvm-bugs@lists.llvm.org

Consider the following code:

define void @foo(i8* %a, i8* %b) {
  ; 1 = MemoryDef(liveOnEntry)
  store i8 0, i8* %a
  ; 2 = MemoryDef(1)
  store i8 0, i8* %b
  ; 3 = MemoryDef(2)
  store i8 0, i8* %a
  ; 4 = MemoryDef(3)
  store i8 0, i8* %b
}

If we use the caching MSSA walker to get the clobbering access of `3` (which is
`1`), we'll cache that result in `3`. If `1` and its corresponding store are
removed from the function -- it's trivially dead, after all -- the cache for
`3` will still be seen as valid, and will still return `1`'s old pointer.

Were we to similarly remove `2`, however, the cache for `3` *would* be properly
invalidated. This is because (I assume) we use "do we have the same store above
us" as a signal for whether the current store has been moved.

This issue does not apply for MemoryUses, since we use operands to do
bookkeeping with those.

The simplest way to fix this seems to be adding an 'optimized' operand to
MemoryDefs, rather than storing 'optimized' as a regular pointer field. Doing
so doesn't loudly break any tests, though I'm unsure if it'll cause functional
changes for existing passes (since with this approach, walking an operands list
for a def now requires extra checks if you don't want to visit every def
twice...). I also don't know offhand how {un,}happy the updater will be with
this. I'll see what I can find out.

-- 
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 6577 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: !isEmpty() && "Nothing selected"

2018-02-26 Thread ClusterFuzz-External via monorail via llvm-bugs


Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Unreproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-26

Type: Bug

New issue 6577 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2:  
ASSERT: !isEmpty() && "Nothing selected"

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

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

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2
Fuzz target binary: llvm-isel-fuzzer--x86_64-O2
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  !isEmpty() && "Nothing selected"
  llvm::IRMutationStrategy::mutate
  llvm::IRMutator::mutateModule

Sanitizer: address (ASAN)

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


Issue filed automatically.

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


Note: This crash might not be reproducible with the provided testcase. That  
said, for the past 14 days we've been seeing this crash frequently. If you  
are unable to reproduce this, please try a speculative fix based on the  
crash stacktrace in the report. The fix can be verified by looking at the  
crash statistics in the report, a day after the fix is deployed. We will  
auto-close the bug if the crash is not seen for 14 days.


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 36333] Supposedly-incorrect error 'constexpr variable... must be initialized by a constant expression'

2018-02-26 Thread via llvm-bugs

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

Richard Smith  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||richard-l...@metafoo.co.uk,
   ||tstel...@redhat.com

--- Comment #2 from Richard Smith  ---
Reduced: https://godbolt.org/g/DwtMmM

struct ObfDescriptor {
  constexpr ObfDescriptor(int n) : n(n) {}
  int n;
};

struct Arr { ObfDescriptor od[1]; };

template struct obf_str_literal {
  static constexpr int sz4 = Dependent;
  constexpr static Arr split = {ObfDescriptor(sz4)};
};

This is the same as bug#36055.

(In reply to Sergey Ignatchenko from comment #0)
> NB: it MIGHT be a different manifestation of recently-fixed bug #36055, but
> if so - it would be nice to re-apply the fix back to Clang 5.0.x (which is
> still the-latest-greatest-officially-released-Clang). 

Clang 6 (in which this is fixed) will be released soon. We have historically
not done point releases for older releases after a new release is shipped.

+Tom Stellard, though, in case we do choose to release a Clang 5.0.2.

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

-- 
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 36475] Unexpected change in layout behaviour for synthetic sections in scripts

2018-02-26 Thread via llvm-bugs

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

Rafael Ávila de Espíndola  changed:

   What|Removed |Added

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

--- Comment #7 from Rafael Ávila de Espíndola  ---
r326137

-- 
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 36528] New: clang-format FixNamespaceComments does not understand namespace aliases

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36528
   Summary: clang-format FixNamespaceComments does not understand
namespace aliases
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: mikhail.strelni...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

# cat test.cpp

namespace nn {}
void f()
{
namespace n = nn;
{
int i;
int j;
}
}

# clang-format -style="{FixNamespaceComments: true}" test.cpp

namespace nn {}
void f() {
  namespace n = nn;
  {
int i;
int j;
  } // namespace n=nn;
}

In this case comment "// namespace n=nn;" should not be added.

-- 
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 36521] clang crashes on passing a coro param to operator new

2018-02-26 Thread via llvm-bugs

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

Andrew Kelley  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Andrew Kelley  ---
I think that https://reviews.llvm.org/D43000 fixes my issue.

Hans, if Brian thinks this is safe to backport to 6.0.0,  I humbly request this
to be added to the release. I am trying to get coroutine support out the door
for my frontend, and I'd rather not wait another LLVM release cycle.

I will verify that this patch solves the issue.

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

[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers

2018-02-26 Thread via llvm-bugs

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

Bug 36521 Summary: clang crashes on passing a coro param to operator new
https://bugs.llvm.org/show_bug.cgi?id=36521

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

-- 
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 35804] [meta] 6.0.0 Release Blockers

2018-02-26 Thread via llvm-bugs

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

Bug 36521 Summary: clang crashes on passing a coro param to operator new
https://bugs.llvm.org/show_bug.cgi?id=36521

   What|Removed |Added

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

-- 
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 36527] New: test_int_t_dwarf failing on FreeBSD

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36527
   Summary: test_*int*_t_dwarf failing on FreeBSD
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org

test_{,u}int{8,16,32,64}_t_dwarf tests are failing on FreeBSD. I intend to
enable tests on the FreeBSD buildbot worker soon so track these failures in a
PR. Further details will be added as they become available.

(see test results snapshot at
http://lists.llvm.org/pipermail/lldb-dev/2018-February/013318.html)

-- 
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 36521] clang crashes on passing a coro param to operator new

2018-02-26 Thread via llvm-bugs

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

Andrew Kelley  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Kelley  ---
I was going to ask for this to be backported to 6.0.0 but since it's a
clang-only change, I don't actually need it in this release. Thanks for the
fix.

-- 
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 36206] UBSan failure (signed integer overflow) in NonnullGlobalConstantsChecker

2018-02-26 Thread via llvm-bugs

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

George Karpenkov  changed:

   What|Removed |Added

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

--- Comment #4 from George Karpenkov  ---
Ooops seems the commit has introduced more problems: 
lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/41/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aregion_store_overflow.c
and
lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/14551/steps/check-clang%20msan/logs/stdio

Reverting until this can be figured out.

-- 
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 36526] New: Clang's debug info does not mark 'this' parameters 'const' but GCC and MSVC do

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36526
   Summary: Clang's debug info does not mark 'this' parameters
'const' but GCC and MSVC do
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org

$ cat t.cpp
struct Foo {
  void f();
};
void Foo::f() {}

$ gcc -c t.cpp -g -o t.o && llvm-dwarfdump t.o
...
0x0097:   DW_TAG_pointer_type
DW_AT_byte_size (0x08)
DW_AT_type  (cu + 0x006f "Foo")

0x009d:   DW_TAG_const_type
DW_AT_type  (cu + 0x0097 "Foo*")

0x00a2:   DW_TAG_subprogram
DW_AT_specification (cu + 0x007b "_ZN3Foo1fEv")
DW_AT_decl_line (4)
DW_AT_object_pointer(cu + 0x00c2)
DW_AT_low_pc(0x)
DW_AT_high_pc   (0x000b)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_object_pointer(cu + 0x00c2)
DW_AT_GNU_all_call_sites(true)

0x00c2: DW_TAG_formal_parameter
  DW_AT_name("this")
  DW_AT_type(cu + 0x009d "const Foo*")
  DW_AT_artificial  (true)
  DW_AT_location(DW_OP_fbreg +0)

$ clang -c t.cpp -g -o t.o && llvm-dwarfdump t.o
...
0x0045:   DW_TAG_pointer_type
DW_AT_type  (cu + 0x002a "Foo")

0x004a:   DW_TAG_subprogram
DW_AT_low_pc(0x)
DW_AT_high_pc   (0x0007)
DW_AT_frame_base(DW_OP_reg7 RSP)
DW_AT_object_pointer(cu + 0x0062)
DW_AT_decl_line (4)
DW_AT_specification (cu + 0x0033 "?f@Foo@@QEAAXXZ")

0x0062: DW_TAG_formal_parameter
  DW_AT_location(DW_OP_fbreg +0)
  DW_AT_name("this")
  DW_AT_type(cu + 0x006f "Foo*")
  DW_AT_artificial  (true)

Also, llvm-dwarfdump applies 'const' in the wrong place. It should appear to
the right of the pointer, as in 'Foo *const this', to indicate that Foo can be
modified, but 'this' cannot be made to point to another object.

Here is MSVC's opinion (note the 'IsConst: 1' below):

$ cl -c t.cpp -Z7 && llvm-readobj -codeview t.obj
...
  Pointer (0x1001) {
TypeLeafKind: LF_POINTER (0x1002)
PointeeType: Foo (0x1000)
PointerAttributes: 0x1040C
PtrType: Near64 (0xC)
PtrMode: Pointer (0x0)
IsFlat: 0
IsConst: 1
IsVolatile: 0
IsUnaligned: 0
IsRestrict: 0
SizeOf: 8
  }
  ArgList (0x1002) {
TypeLeafKind: LF_ARGLIST (0x1201)
NumArgs: 0
Arguments [
]
  }
  MemberFunction (0x1003) {
TypeLeafKind: LF_MFUNCTION (0x1009)
ReturnType: void (0x3)
ClassType: Foo (0x1000)
ThisType: const Foo* (0x1001)
CallingConvention: NearC (0x0)
FunctionOptions [ (0x0)
]
NumParameters: 0
ArgListType: () (0x1002)
ThisAdjustment: 0
  }

Given that both mainstream compilers disagree with us on this, we should
probably change our output.

-- 
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 36525] New: std::bad_alloc : Process::ReadModuleFromMemory is passed bogus size_to_read when "target modules load" libart.so

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36525
   Summary: std::bad_alloc : Process::ReadModuleFromMemory is
passed bogus size_to_read when "target modules load"
libart.so
   Product: lldb
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: anthony.louis.e...@gmail.com
CC: llvm-bugs@lists.llvm.org

(lldb) thread backtrace all
* thread #1, name = 'lldb', stop reason = signal SIGABRT
  * frame #0: 0x749d2860 libc.so.6`__GI_raise + 272
frame #1: 0x749d3ec9 libc.so.6`__GI_abort + 457
frame #2: 0x74de3d57
libstdc++.so.6`__gnu_cxx::__verbose_terminate_handler() at vterminate.cc:95
frame #3: 0x74de18c6
libstdc++.so.6`__cxxabiv1::__terminate(handler=)()) at
eh_terminate.cc:47
frame #4: 0x74de1913 libstdc++.so.6`std::terminate() at
eh_terminate.cc:57
frame #5: 0x74de1b68
libstdc++.so.6`__cxxabiv1::__cxa_throw(obj=, tinfo=,
dest=)(void *)) at eh_throw.cc:93
frame #6: 0x74de20cf libstdc++.so.6`operator new(sz=)
at new_op.cc:54
frame #7: 0x7588f8c4
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined] __gnu_cxx::new_allocator::allocate(this=, (null)=, __n=) at
new_allocator.h:111
frame #8: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined] std::allocator_traits::allocate(__a=, __n=) at alloc_traits.h:436
frame #9: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) at stl_vector.h:172
frame #10: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined] std::_Vector_base >::_M_create_storage(__n=13151649335953326080,
this=) at stl_vector.h:187
frame #11: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined]
_ZNSt12_Vector_baseIhSaIhEEC4EmRKS0_(__a=0x55dbfd48,
__n=13151649335953326080, this=) at stl_vector.h:138
frame #12: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined]
_ZNSt6vectorIhSaIhEEC4EmRKhRKS0_(__a=0x55dbfd48, __value=,
__n=13151649335953326080, this=) at stl_vector.h:297
frame #13: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) at vector.tcc:242
frame #14: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long,
unsigned char) [inlined] std::vector >::assign(__val=, __n=13151649335953326080,
this=0x55dbfd48) at stl_vector.h:502
frame #15: 0x7588f8be
liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(this=0x55dbfd40,
n=13151649335953326080, ch=) at DataBufferHeap.cpp:30
frame #16: 0x756615fd
liblldb.so.5`lldb_private::Module::GetMemoryObjectFile(std::shared_ptr
const&, unsigned long, lldb_private::Status&, unsigned long) [inlined]
std::enable_if::value),
std::unique_ptr >::type
llvm::make_unique((null)=, (null)=) at STLExtras.h:944
frame #17: 0x756615e6
liblldb.so.5`lldb_private::Module::GetMemoryObjectFile(this=0x55dbfff0,
process_sp=std::__shared_ptr::element_type @
0x5591fc20, header_addr=3068708324, error=0x7fffc2a0,
size_to_read=13151649335953326080) at Module.cpp:333
frame #18: 0x7580384f
liblldb.so.5`lldb_private::Process::ReadModuleFromMemory(this=0x5591fc20,
file_spec=, header_addr=3068708324,
size_to_read=13151649335953326080) at Process.cpp:2632
frame #19: 0x759a8e9b liblldb.so.5`bool
JITLoaderGDB::ReadJITDescriptorImpl(this=0x5596cb60,
all_entries=true) at JITLoaderGDB.cpp:318
frame #20: 0x759a7485
liblldb.so.5`JITLoaderGDB::SetJITBreakpoint(lldb_private::ModuleList&) at
JITLoaderGDB.cpp:202
frame #21: 0x759a72fd
liblldb.so.5`JITLoaderGDB::SetJITBreakpoint(this=0x5596cb60,
module_list=)
frame #22: 0x7587f6d0
liblldb.so.5`lldb_private::JITLoaderList::ModulesDidLoad(this=0x55967760,
module_list=0x7fffc790) at JITLoaderList.cpp:55
frame #23: 0x7580853f
liblldb.so.5`lldb_private::Process::ModulesDidLoad(this=0x5591fc20,
module_list=0x7fffc790) at Process.cpp:5899
frame #24: 0x75ab259a
liblldb.so.5`lldb_private::process_gdb_remote::ProcessGDBRemote::ModulesDidLoad(this=0x5591fc20,
module_list=) at ProcessGDBRemote.cpp:4763
frame #25: 0x7583e69a

[llvm-bugs] [Bug 36523] New: /SUBSYSTEM not taken into account for automatic /ENTRY detection

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36523
   Summary: /SUBSYSTEM not taken into account for automatic /ENTRY
detection
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: COFF
  Assignee: unassignedb...@nondot.org
  Reporter: alexandre.ga...@ubisoft.com
CC: llvm-bugs@lists.llvm.org

We have a case where both "main" and "WinMain" are defined in different .libs
being linked in. We also provide /SUBSYSTEM:WINDOWS on the command-line.

As per spec
(https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem)
specifying /SUBSYSTEM:CONSOLE shall select "main" or "wmain"; and specifying
/SUBSYSTEM:WINDOWS shall select "WinMain" or "wWinMain", whichever is present.

Given the list in lld\COFF\Driver.cpp, LinkerDriver::findDefaultEntry(),
Config->Subsystem is not taken account, which leads to "main" being selected.
For this exact same case, link.exe selects "WinMain", which follows the
/SUBSYSTEM selector.

-- 
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 36524] New: [LV] Lost vectorization opportunity

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36524
   Summary: [LV] Lost vectorization opportunity
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: dneil...@azul.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19965
  --> https://bugs.llvm.org/attachment.cgi?id=19965=edit
Sample IR

IR attached:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: uwtable
define void @foo() #0 {
entry:
  br label %loop

loop:
  %0 = phi i64 [ 2, %entry ], [ %3, %loop ]
  %1 = and i64 %0, 4294967295
  %2 = trunc i64 %0 to i32
  %3 = add nuw nsw i64 %1, 1
  %4 = icmp sgt i32 %2, 80
  br i1 %4, label %exit, label %loop

exit:
  ret void
}

attributes #0 = { uwtable "target-cpu"="bdver1"
"target-features"="+sse2,+cx16,-tbm,-avx512ifma,-gfni,-sha,+fma4,-vpclmulqdq,+prfchw,-bmi2,-xsavec,-fsgsbase,+popcnt,+aes,-avx512bitalg,-xsaves,-avx512er,-avx512vnni,-avx512vpopcntdq,-clwb,-avx512f,-clzero,-pku,+mmx,+lwp,-rdpid,+xop,-rdseed,-ibt,+sse4a,-avx512bw,-clflushopt,+xsave,-avx512vbmi2,-avx512vl,-avx512cd,+avx,-vaes,-rtm,-fma,-bmi,-rdrnd,-mwaitx,+sse4.1,+sse4.2,-avx2,+sse,+lzcnt,+pclmul,-prefetchwt1,-f16c,+ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-movbe,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3"
}



When run through the loop vectorizer with ToT we do not vectorize this loop.
However, it did once vectorize in the fairly recent past. There's a bit of a
history on this one...

https://reviews.llvm.org/rL320463 -- is the last LoopVectorizer.cpp change that
vectorizes this loop.

https://reviews.llvm.org/rL320672 -- breaks the test, with an assertion in
VPlan:
r320672 | dorit.nuzman | 2017-12-14 01:56:31 -0600 (Thu, 14 Dec 2017) | 26
lines

[LV] Support efficient vectorization of an induction with redundant casts
==
Assertion failed: (!hasVectorValue(Key, Part) && "Vector value already set for
part"), function setVectorValue, file lib/Transforms/Vectorize/VPlan.h, line
166.
0  opt  0x00010b8e44bc
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  opt  0x00010b8e4ab9
PrintStackTraceSignalHandler(void*) + 25
2  opt  0x00010b8e0549 llvm::sys::RunSignalHandlers() +
425
3  opt  0x00010b8e4e72 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x7fff64326f5a _sigtramp + 26
5  libdyld.dylib0x7fff640a5249 dyldGlobalLockRelease() + 0
6  libsystem_c.dylib0x7fff64151312 abort + 127
7  libsystem_c.dylib0x7fff64119368 basename_r + 0
8  opt  0x00010ba87eb0
llvm::VectorizerValueMap::setVectorValue(llvm::Value*, unsigned int,
llvm::Value*) + 160
9  opt  0x00010ba88100
llvm::InnerLoopVectorizer::recordVectorLoopValueForInductionCast(llvm::InductionDescriptor
const&, llvm::Value*, unsigned int, unsigned int) + 208
10 opt  0x00010ba89375
llvm::InnerLoopVectorizer::widenIntOrFpInduction(llvm::PHINode*,
llvm::TruncInst*) + 2533
11 opt  0x00010bac0ed0 (anonymous
namespace)::VPWidenIntOrFpInductionRecipe::execute(llvm::VPTransformState&) +
144
12 opt  0x00010bb64bfa
llvm::VPBasicBlock::execute(llvm::VPTransformState*) + 842
13 opt  0x00010bb66037
llvm::VPlan::execute(llvm::VPTransformState*) + 855
14 opt  0x00010ba9a22e
llvm::LoopVectorizationPlanner::executePlan(llvm::InnerLoopVectorizer&,
llvm::DominatorTree*) + 430
15 opt  0x00010baa2ad2
llvm::LoopVectorizePass::processLoop(llvm::Loop*) + 8482

https://reviews.llvm.org/rL322473 -- Changes the breakage. It's still broken,
but the assert has changed
r322473 | andrei.elovikov | 2018-01-15 04:56:07 -0600 (Mon, 15 Jan 2018) | 24
lines

[LV] Don't call recordVectorLoopValueForInductionCast for newly-created IV from
a trunc.
==
Assertion failed: (!hasScalarValue(Key, Instance) && "Scalar value already
set"), function setScalarValue, file lib/Transforms/Vectorize/VPlan.h, line
173.
0  opt  0x00010429f82c
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  opt  0x00010429fe29
PrintStackTraceSignalHandler(void*) + 25
2  opt  0x00010429b8b9 llvm::sys::RunSignalHandlers() +
425
3  opt  0x0001042a01e2 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x7fff64326f5a _sigtramp + 26
5  libdyld.dylib0x7fff640a5249 dyldGlobalLockRelease() + 0
6  libsystem_c.dylib0x7fff64151312 abort + 127
7  libsystem_c.dylib0x7fff64119368 basename_r + 0
8  opt  0x00010444662f

[llvm-bugs] Issue 4985 in oss-fuzz: llvm/clang-fuzzer: Heap-use-after-free in clang::APValue::swap

2018-02-26 Thread vsap… via monorail via llvm-bugs



Comment #5 on issue 4985 by vsap...@gmail.com: llvm/clang-fuzzer:  
Heap-use-after-free in clang::APValue::swap

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

Fixed in https://llvm.org/viewvc/llvm-project?view=revision=325997

--
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 36206] UBSan failure (signed integer overflow) in NonnullGlobalConstantsChecker

2018-02-26 Thread via llvm-bugs

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

George Karpenkov  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 36522] New: system-header-prefix does not apply to headers included by a headermap

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36522
   Summary: system-header-prefix does not apply to headers
included by a headermap
   Product: clang
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: neuber...@gmail.com
CC: llvm-bugs@lists.llvm.org

The --system-header-prefix flag does not apply to headers included with a
headermap file.

Include a file with warnings with "-I my_include_dir" and system-header-prefix
can be used to ignore the warnings.

Change the -I flag to "-I my_header_map.hmap" and leave the
system-header-prefix to be the same, and you will now see warnings from those
header files.

-- 
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 36520] New diagnostic -Wzero-as-null-pointer-constant warns on code in system headers.

2018-02-26 Thread via llvm-bugs

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

Lukasz Anforowicz  changed:

   What|Removed |Added

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

--- Comment #2 from Lukasz Anforowicz  ---
Good call - thanks for taking a look.  The include path was indeed specified
via -I... rather than -isystem:
-I../../build/linux/debian_stretch_amd64-sysroot/usr/lib/x86_64-linux-gnu/glib-2.0/include.

Let me resolve this bug as WontFix/WAI/ByDesign.

third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
obj/base/base/message_pump_glib.o.d -DUSE_SYMBOLIZE -DV8_DEPRECATION_WARNINGS
-DDCHECK_ALWAYS_ON=1 -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1
-DUSE_X11=1 -DNO_TCMALLOC -DMEMORY_TOOL_REPLACES_ALLOCATOR
-DMEMORY_SANITIZER_INITIAL_SIZE -DADDRESS_SANITIZER -DFULL_SAFE_BROWSING
-DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD
-DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -DCR_CLANG_REVISION=\"325667-1\" -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -DCOMPONENT_BUILD -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBASE_IMPLEMENTATION
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -I../.. -Igen
-I../../build/linux/debian_stretch_amd64-sysroot/usr/include/glib-2.0
-I../../build/linux/debian_stretch_amd64-sysroot/usr/lib/x86_64-linux-gnu/glib-2.0/include
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__=
-funwind-tables -fPIC -pipe -B../../third_party/binutils/Linux_x64/Release/bin
-pthread -fcolor-diagnostics -Xclang -mllvm -Xclang
-instcombine-lower-dbg-declare=0 -no-canonical-prefixes -m64 -march=x86-64
-Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety
-Wzero-as-null-pointer-constant -Wno-missing-field-initializers
-Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default
-Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override
-Wno-undefined-var-template -Wno-nonportable-include-path
-Wno-address-of-packed-member -Wno-unused-lambda-capture
-Wno-user-defined-warnings -Wno-enum-compare-switch
-Wno-null-pointer-arithmetic -fno-omit-frame-pointer -g1 -gline-tables-only
-gcolumn-info -fsanitize=address -fsanitize-address-use-after-scope
-fsanitize-blacklist=../../tools/memory/asan/blacklist.txt -fvisibility=hidden
-Xclang -load -Xclang
../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so
-Xclang -add-plugin -Xclang find-bad-constructs -Xclang
-plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene
-Wstring-conversion -Wtautological-overlap-compare -Wglobal-constructors
-Wexit-time-destructors -Wexit-time-destructors -Wshadow
-Wexit-time-destructors -O2 -fno-ident -fdata-sections -ffunction-sections
-std=gnu++14 -fno-exceptions -fno-rtti -nostdinc++
-isystem../../buildtools/third_party/libc++/trunk/include
-isystem../../buildtools/third_party/libc++abi/trunk/include
--sysroot=../../build/linux/debian_stretch_amd64-sysroot
-fvisibility-inlines-hidden -c ../../base/message_loop/message_pump_glib.cc -o
obj/base/base/message_pump_glib.o

-- 
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 36520] New: New diagnostic -Wzero-as-null-pointer-constant warns on code in system headers.

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36520
   Summary: New diagnostic -Wzero-as-null-pointer-constant warns
on code in system headers.
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: luka...@chromium.org
CC: llvm-bugs@lists.llvm.org

This is a follow-up for https://bugs.llvm.org/show_bug.cgi?id=33771 - even
after this bug got fixed, some system headers result in warnings/errors:

In file included from ../../base/message_loop/message_pump_glib.cc:10:
In file included from
../../build/linux/debian_stretch_amd64-sysroot/usr/include/glib-2.0/glib.h:50:
In file included from
../../build/linux/debian_stretch_amd64-sysroot/usr/include/glib-2.0/glib/ghash.h:33:
In file included from
../../build/linux/debian_stretch_amd64-sysroot/usr/include/glib-2.0/glib/glist.h:32:
   
../../build/linux/debian_stretch_amd64-sysroot/usr/include/glib-2.0/glib/gmem.h:192:10:
error: zero as null pointer constant [-Werror,-Wzero-as-null-pointer-constant]
  *ptr = NULL;
 ^~~~
 nullptr
   
../../third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/include/stddef.h:100:18:
note: expanded from macro 'NULL'
#define NULL __null

base/message_loop/message_pump_glib.cc looks like this (in particular, note
that |#include | rather than |#include "foo.h"| was used):

...
#include "base/message_loop/message_pump_glib.h"

#include 
#include 

#include   // <--- THIS PULLS IN SYSTEM HEADERS THAT RESULT IN THE
WARNING

#include "base/lazy_instance.h"
#include "base/logging.h"
...

-- 
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 36519] New: Regression: br_cc not formed after r325892

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36519
   Summary: Regression: br_cc not formed after r325892
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: qcolom...@apple.com
CC: llvm-bugs@lists.llvm.org

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

Author: deadalnix
Date: Fri Feb 23 03:50:42 2018
New Revision: 325892

URL: http://llvm.org/viewvc/llvm-project?rev=325892=rev
Log:
[DAGCOmbine] Ensure that (brcond (setcc ...)) is handled in a canonical manner.

Summary:
There are transformation that change setcc into other constructs, and transform
that try to reconstruct a setcc from the brcond condition. Depending on what
order these transform are done, the end result differs.

Most of the time, it is preferable to get a setcc as a brcond argument (and
this is why brcond try to recreate the setcc in the first place) so we ensure
this is done every time by also doing it at the setcc level when the only user
is a brcond.

I am seeing cases where this change has actually the opposite effect than was
what intended, if I understood correctly.

In particular, I am seeing a case where we used to generate brcond(setcc(and))
from brcond(xor(and)), but now we end up with brcond(or(xor)). Thus, we failed
to produce br_cc.

Attached a reproducer:
llc -mtriple powerpc-- reduced.ll -o - -debug-only=isel

You’ll see in the debug output those diffs:
 Optimized legalized selection DAG: %bb.3 't1_false1.split:false1.split'
 SelectionDAG has 16 nodes:
   t0: ch = EntryToken
-t8: i1,ch = CopyFromReg t0, Register:i1 %3
+  t8: i1,ch = CopyFromReg t0, Register:i1 %3
+t16: i1 = xor t8, Constant:i1<-1>
   t2: f32,ch = CopyFromReg t0, Register:f32 %0
   t4: f32,ch = CopyFromReg t0, Register:f32 %1
-t6: i1 = setcc t2, t4, setolt:ch
-  t9: i1 = and t8, t6
-t18: ch = br_cc t0, setne:ch, t9, Constant:i1<-1>,
BasicBlock:ch
-  t15: ch = br t18, BasicBlock:ch
+t21: i1 = setcc t2, t4, setuge:ch
+  t18: i1 = or t16, t21
+t19: ch = brcond t0, t18, BasicBlock:ch ###
<— we don’t get a br_cc anymore
+  t15: ch = br t19, BasicBlock:ch

-- 
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 36401] bool runIPSCCP(llvm::Module&, const llvm::DataLayout&, const llvm::TargetLibraryInfo*): Assertion `Folded && "Expect TermInst on constantint or blockaddress to be folded"'

2018-02-26 Thread via llvm-bugs

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

Florian Hahn  changed:

   What|Removed |Added

 CC||florian.h...@arm.com
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Florian Hahn  ---
The reproducer looks like the reproducer for
https://bugs.llvm.org/show_bug.cgi?id=35723. Marking as duplicate.

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

-- 
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 36518] New: cbrt() function cannot be vectorized through OpenMP

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36518
   Summary: cbrt() function cannot be vectorized through OpenMP
   Product: OpenMP
   Version: unspecified
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Clang Compiler Support
  Assignee: unassignedclangb...@nondot.org
  Reporter: j...@freebsd.org
CC: llvm-bugs@lists.llvm.org

Created attachment 19962
  --> https://bugs.llvm.org/attachment.cgi?id=19962=edit
reproduction of issue

A trivial loop using cbrt() from cmath in its body cannot be vectorized.
Compiling attached gives the following (on FreeBSD with LLVM devel as of
beginning of February):

$ clang++-devel -O3 -Rpass=loop-vectorize -Rpass-missed=loop-vectorize
-Rpass-analysis=loop-vectorize -fsave-optimization-record -fopenmp -o cbrt
cbrt.cpp 
cbrt.cpp:13:12: remark: loop not vectorized: call instruction cannot be
  vectorized [-Rpass-analysis]
res[x] = cbrt((double) x);
 ^
cbrt.cpp:11:10: remark: loop not vectorized (Force=true)
  [-Rpass-missed=loop-vectorize]
#pragma omp simd
^
cbrt.cpp:11:10: warning: loop not vectorized: failed explicitly specified loop
  vectorization [-Wpass-failed=loop-vectorize]
1 warning generated.

What is necessary to have cbrt() vectorizable? This works with recent Intel
compilers on Linux and GCC seems to also be capable to do this properly.

-- 
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 11006] scan-build of GCC 4.5.3 crash with clang r140417

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||ale...@google.com
 Status|NEW |RESOLVED

--- Comment #6 from Alexander Kornienko  ---
It's been more than 6 years. This bug is hardly relevant now. If you can still
reproduce the issue, please open a new issue with an isolated test case.

-- 
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 10130] 2 scan-build crashes

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Alexander Kornienko  ---
It's been more than 6 years. This bug is hardly relevant now. If you can still
reproduce the issue, please open a new issue with an isolated test case.

-- 
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 4537 in oss-fuzz: llvm/clang-fuzzer: ASSERT: isa(Val) && "cast() argument of incompatible type!"

2018-02-26 Thread sheriff… via monorail via llvm-bugs


Updates:
Labels: Deadline-Approaching

Comment #7 on issue 4537 by sheriff...@chromium.org: llvm/clang-fuzzer:  
ASSERT: isa(Val) && "cast() argument of incompatible type!"

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

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 6573 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Heap-use-after-free in llvm::LoopVectorizationLegality::canVectorize

2018-02-26 Thread ClusterFuzz-External via monorail via llvm-bugs


Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-26

Type: Bug-Security

New issue 6573 by ClusterFuzz-External:  
llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Heap-use-after-free in  
llvm::LoopVectorizationLegality::canVectorize

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

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

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize
Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Heap-use-after-free READ 4
Crash Address: 0x6060d600
Crash State:
  llvm::LoopVectorizationLegality::canVectorize
  llvm::LoopVectorizePass::processLoop
  llvm::LoopVectorizePass::runImpl

Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802190622:201802200626


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


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 17746] Analyzer crashes

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 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 16664] static analyzer illegal instruction crash with temporary destructors enabled

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Resolution|--- |INVALID
 Status|REOPENED|RESOLVED

--- Comment #9 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 17212] clang++ scan-build (2.75) crashes when analyzing this file

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ale...@google.com
 Resolution|--- |INVALID

--- Comment #3 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 16999] Analyzer crash

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 16945] clang analyzer crash when compiling hash.c from bahamut ircd.

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 15308] Analyzer crash

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
 CC||ale...@google.com

--- Comment #2 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 13473] clang --analyze crashes on C file

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||ale...@google.com
 Status|NEW |RESOLVED

--- Comment #8 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 13847] clang analyzer crashes when compiling sqlite3

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
 CC||ale...@google.com

--- Comment #8 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 13680] Static analyzer crash

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED
 CC||ale...@google.com

--- Comment #4 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 12004] clang-sa crash when accessing a CFType in a union

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 10827] Crash when analyzing a file

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||ale...@google.com
 Status|NEW |RESOLVED

--- Comment #5 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 5180] checker-224 crashes analyzing wine-1.1.31

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

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

-- 
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 6545] [static analysis, c++] Crashes of clang during compilation/static-analyzer of mupen64plus 1.99.3

2018-02-26 Thread via llvm-bugs

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

Alexander Kornienko  changed:

   What|Removed |Added

 CC||ale...@google.com
 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Alexander Kornienko  ---
The report is hardly relevant now. If you still get the analyzer to crash,
please open another bug with an isolated test case.

-- 
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 36490] Segmentation fault when accessing any Python script object

2018-02-26 Thread via llvm-bugs

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

Evgeny Morozov  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Evgeny Morozov  ---
OK, it turns out there is a version of libsosplugin.so that works with later
LLDB versions. I still get a Segmentation fault in 5.0 (but not 3.9 or 4.0):

$ lldb-5.0
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> lldb
>>> Segmentation fault (core dumped)

Sometimes it works the first time, but crashes the second time:

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> lldb
>>> 

>>> lldb
Segmentation fault (core dumped)

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

[llvm-bugs] [Bug 36515] New: Regression when empty script sections have explict address

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36515
   Summary: Regression when empty script sections have explict
address
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: release blocker
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org

This bug is a regression caused by r325887. Consider the following script and
assembly file:

// test.script
PHDRS
{
ph_headers  PT_PHDR PHDRS;
ph_text PT_LOAD FILEHDR PHDRS  FLAGS (0x1 | 0x4);
}

SECTIONS
{
  . = 0x2000 + SIZEOF_HEADERS;
  .text : { *(.text*) } : ph_text

  .debug_info 0 : { *(.debug_info) }
}

// test.s
.text
.globl _start
_start:
nop

Previous to the above revision, LLD would happily link this case, and discard
.debug_info, since it was empty. However, now it attempts to assign .debug_info
an address of zero, and keeps it because of the change made. The exact result
depends on the system I tested it on. On Windows I got the following error:
C:\Work\TempWork> C:\llvm\build\Debug\bin\ld.lld.exe test.o -o test.elf -T
.\test.script
C:\llvm\build\Debug\bin\ld.lld.exe: error: failed to open test.elf: The
requested operation cannot be performed on a file with a user-mapped section
open.

On Linux, I get a segmentation fault. I haven't debugged the Linux failure, but
I assume that it has the same cause (note - I was using a slightly different
revision of LLD for this):
#0 0x004326dd llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x0043276e PrintStackTraceSignalHandler(void*)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x00430b56 llvm::sys::RunSignalHandlers()
/home/binutils/llvm/llvm/lib/Support/Signals.cpp:49:0
#3 0x00432075 SignalHandler(int)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x7fd1dd2b4330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x7fd1dc313bf4
/build/eglibc-SvCtMH/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:142:0
#6 0x00600a03 void
lld::elf::InputSection::writeTo >(unsigned char*)
/home/binutils/llvm/llvm/tools/lld/ELF/InputSection.cpp:784:0
#7 0x0062def6 void
lld::elf::OutputSection::writeTo >(unsigned char*)::{lambda(unsigned long)#1}::operator()(unsigned long)
const /home/binutils/llvm/llvm/tools/lld/ELF/OutputSections.cpp:244:0
#8 0x0062def6 void
lld::elf::OutputSection::writeTo >(unsigned char*)::{lambda(unsigned long)#1}::operator()(unsigned long)
const (../llvm/build/bin/ld.lld+0x62def6)
#9 0x00631f3c std::_Function_handler >(unsigned char*)::{lambda(unsigned long)#1}>::_M_invoke(std::_Any_data
const&, unsigned long) /usr/include/c++/4.8/functional:2073:0
#10 0x005af253 std::function::operator()(unsigned
long) const /usr/include/c++/4.8/functional:2472:0
#11 0x005af1d0 void
llvm::parallel::detail::parallel_for_each_n >(unsigned long, unsigned long, std::function) /home/binutils/llvm/llvm/include/llvm/Support/Parallel.h:182:0
#12 0x005aee07 void llvm::parallel::for_each_n
>(llvm::parallel::parallel_execution_policy, unsigned long, unsigned long,
std::function)
/home/binutils/llvm/llvm/include/llvm/Support/Parallel.h:240:0
#13 0x005aecbe lld::parallelForEachN(unsigned long, unsigned long,
std::function)
/home/binutils/llvm/llvm/tools/lld/include/lld/Common/Threads.h:79:0
#14 0x0062e257 void
lld::elf::OutputSection::writeTo >(unsigned char*)
/home/binutils/llvm/llvm/tools/lld/ELF/OutputSections.cpp:253:0
#15 0x006e356e (anonymous
namespace)::Writer
>::writeSections() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:2215:0
#16 0x006d812a (anonymous
namespace)::Writer
>::run() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:467:0
#17 0x0070bbb8 void
lld::elf::writeResult
>() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:128:0
#18 0x0058d664 void
lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&)
/home/binutils/llvm/llvm/tools/lld/ELF/Driver.cpp:1174:0
#19 0x0057e39f lld::elf::LinkerDriver::main(llvm::ArrayRef) /home/binutils/llvm/llvm/tools/lld/ELF/Driver.cpp:387:0
#20 0x0057b665 lld::elf::link(llvm::ArrayRef, bool,
llvm::raw_ostream&)

[llvm-bugs] [Bug 36351] Merge r324747 into the 6.0 branch : Reapply "AMDGPU: Add 32-bit constant address space"

2018-02-26 Thread via llvm-bugs

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

Hans Wennborg  changed:

   What|Removed |Added

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

-- 
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 35804] [meta] 6.0.0 Release Blockers

2018-02-26 Thread via llvm-bugs

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

Bug 36351 Summary: Merge r324747 into the 6.0 branch : Reapply "AMDGPU: Add 
32-bit constant address space"
https://bugs.llvm.org/show_bug.cgi?id=36351

   What|Removed |Added

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

-- 
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 36514] New: Segfault in llvm::object::MachOObjectFile::getSectionName

2018-02-26 Thread via llvm-bugs

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

Bug ID: 36514
   Summary: Segfault in
llvm::object::MachOObjectFile::getSectionName
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Object
  Assignee: unassignedb...@nondot.org
  Reporter: jdevliegh...@apple.com
CC: llvm-bugs@lists.llvm.org

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

$ llvm-objdump -r sibling.o

sibling.o:  file format Mach-O 32-bit ppc

RELOCATION RECORDS FOR [__DWARF,__debug_info]:
0  llvm-objdump 0x000105918955 PrintStackTrace(void*) + 37
1  llvm-objdump 0x000105918d84 SignalHandler(int) + 468
2  libsystem_platform.dylib 0x7fff5a3c1f5a _sigtramp + 26
3  libsystem_platform.dylib 0x0001066042c4 _sigtramp + 18446603343404213124
4  llvm-objdump 0x0001058e13f1
llvm::object::MachOObjectFile::getSectionName(llvm::object::DataRefImpl,
llvm::StringRef&) const + 289
5  llvm-objdump 0x0001058e2d80
llvm::object::MachOObjectFile::printRelocationTargetName(llvm::InMemoryStruct&,
llvm::raw_string_ostream&) const + 608
6  llvm-objdump 0x0001058e337f
llvm::object::MachOObjectFile::getRelocationValueString(llvm::object::DataRefImpl,
llvm::SmallVectorImpl&) const + 1087
7  llvm-objdump 0x0001057df625
DumpObject(llvm::object::ObjectFile const*) + 2037
8  llvm-objdump 0x0001057de49c main + 1388
9  libdyld.dylib0x7fff5a0be015 start + 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

51 matches

Mail list logo