[llvm-bugs] [Bug 30674] New: [libtooling] ASTContext::getObjCInstanceType never returns null - it creates typedef if type is not known

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

Bug ID: 30674
   Summary: [libtooling] ASTContext::getObjCInstanceType never
returns null - it creates typedef if type is not known
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: libclang
  Assignee: unassignedclangb...@nondot.org
  Reporter: akotul...@fb.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

Docs for getObjCInstanceType say:
"Retrieve the Objective-C "instancetype" type, if already known;
otherwise, returns a NULL type;"

This is obviously not true, by looking at source code, I also tested it on
clang trunk from August to confirm. It would be great if there was a way to
know if getObjCInstanceType is known or not without creating it.



This is how source code looks like:
QualType getObjCInstanceType() {
  return getTypeDeclType(getObjCInstanceTypeDecl());
}

TypedefDecl *getObjCInstanceTypeDecl() {
  if (!ObjCInstanceTypeDecl)
ObjCInstanceTypeDecl = TypedefDecl::Create(...)
  }
  return ObjCInstanceTypeDecl;
}

-- 
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 30675] New: atomic::compare_exchange returns wrong value

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

Bug ID: 30675
   Summary: atomic::compare_exchange returns wrong value
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: dvyu...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified

llvm/clang/libc++ are on rev 271514.

Test is:

#include 
#include 
#include 
#include 

template
struct MyStruct {
  char data[kSize];

  explicit MyStruct(char v = 0) noexcept {
memset(&data[0], v, sizeof(data));
  }

  bool operator == (const MyStruct &other) const {
return memcmp(&data[0], &other.data[0], sizeof(data)) == 0;
  }

  bool operator != (const MyStruct &other) const {
return !(*this == other);
  }

  operator int() const {
return data[0];
  }
};

int main() {
  typedef MyStruct<6> T;
  std::atomic a(T(0));
  T cmp(17);
  if (a.compare_exchange_strong(cmp, T(18), std::memory_order_acquire)) {
fprintf(stderr, "%d: bad atomic value %d\n", __LINE__, (int)cmp);
exit(1);
  }
  if (cmp != T(0)) {
fprintf(stderr, "%d: bad atomic value %d\n", __LINE__, (int)cmp);
exit(1);
  }
}

The test works with libstdc++:

$ bin/clang++ /tmp/atomic.cc -std=c++11 -latomic && ./a.out

But fails with libc++:

$ bin/clang++ /tmp/atomic.cc -std=c++11 -stdlib=libc++ -latomic &&
LD_LIBRARY_PATH=./lib/ ./a.out
36: bad atomic value 17

-- 
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 30486] [InstCombine] Crash in InstructionCombining.cpp due to a cast failure in switch control condition

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

Simon Pilgrim  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Pilgrim  ---
Fixed in rL284000

-- 
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 18926] [Meta] ARM Integrated assembler support

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

Bug 18926 depends on bug 18920, which changed state.

Bug 18920 Summary: [AArch64] CMP + label arithmetic not supported
https://llvm.org/bugs/show_bug.cgi?id=18920

   What|Removed |Added

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

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

[llvm-bugs] [Bug 18920] [AArch64] CMP + label arithmetic not supported

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

Diana Picus  changed:

   What|Removed |Added

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

--- Comment #7 from Diana Picus  ---
r283862 adds support for label arithmetic, and the others seem to have been
fixed in the past. I'm closing this one, for other issues with the AArch64
assembler please open separate bug reports.

-- 
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 30676] New: Some tests fail when clang is build with only one, non host target

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

Bug ID: 30676
   Summary: Some tests fail when clang is build with only one, non
host target
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: arpha...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When I build llvm and clang with only the XCore target and run clang's tests, I
get 51 test failures (clang r284007):

Failing Tests (51):
Clang :: ASTMerge/anonymous-fields.cpp
Clang :: ASTMerge/codegen-body.c
Clang :: CodeGen/2005-09-24-AsmUserPrefix.c
Clang :: CodeGen/2009-04-23-dbg.c
Clang :: CodeGen/2009-07-31-DbgDeclare.c
Clang :: CodeGen/attribute-section-data-common.c
Clang :: CodeGen/extern-weak.c
Clang :: CodeGen/libcalls-fno-builtin.c
Clang :: CodeGen/pointer-arithmetic.c
Clang :: CodeGenCXX/2010-03-09-AnonAggregate.cpp
Clang :: CodeGenCXX/crash.cpp
Clang :: CodeGenCXX/debug-info-byval.cpp
Clang :: CodeGenCXX/debug-info-ctor2.cpp
Clang :: CodeGenCXX/debug-info-member.cpp
Clang :: CodeGenCXX/debug-info-method-spec.cpp
Clang :: CodeGenObjC/2007-05-02-Strong.m
Clang :: CodeGenObjC/2009-01-21-invalid-debug-info.m
Clang :: CodeGenObjC/blocks-ivar-debug.m
Clang :: CodeGenObjC/debug-info-class-extension.m
Clang :: CodeGenObjC/debug-info-class-extension2.m
Clang :: CodeGenObjC/debug-info-class-extension3.m
Clang :: CodeGenObjC/debug-info-linkagename.m
Clang :: CodeGenObjC/debug-info-property.m
Clang :: CodeGenObjC/debug-info-property2.m
Clang :: CodeGenObjC/debug-info-property4.m
Clang :: CodeGenObjC/debug-info-property5.m
Clang :: CodeGenObjC/illegal-UTF8.m
Clang :: CodeGenObjC/property-dbg.m
Clang :: CodeGenOpenCL/denorms-are-zero.cl
Clang :: Driver/cc-print-options.c
Clang :: Driver/clang_f_opts.c
Clang :: Driver/linker-opts.c
Clang :: Driver/modules-ts.cpp
Clang :: Driver/no-canonical-prefixes.c
Clang :: Driver/output-file-cleanup.c
Clang :: Driver/unknown-arg.c
Clang :: Frontend/ir-support.c
Clang :: Modules/DebugInfoSubmoduleImport.c
Clang :: Modules/DebugInfoSubmodules.c
Clang :: Modules/DebugInfoTransitiveImport.m
Clang :: Modules/ExtDebugInfo.cpp
Clang :: Modules/ExtDebugInfo.m
Clang :: Modules/ModuleDebugInfo.cpp
Clang :: Modules/ModuleDebugInfo.m
Clang :: Modules/ModuleModuleDebugInfo.cpp
Clang :: Modules/debug-info-moduleimport.m
Clang :: Modules/module_file_info.m
Clang :: PCH/debug-info-pch-path.c
Clang :: SemaCUDA/exceptions-host-device.cu
Clang :: SemaCUDA/vla-host-device.cu
Clang :: SemaCXX/warn-unused-local-typedef-serialize.cpp

Run the following commands to reproduce this issue (on X86 host):

cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_TARGETS_TO_BUILD="XCore"

ninja check-clang

-- 
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 30329] MSVC build failure: _recalloc redefinition in rt_asan

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

Reid Kleckner  changed:

   What|Removed |Added

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

--- Comment #16 from Reid Kleckner  ---
Great, thanks to Hans for diagnosing the problem!

-- 
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 30677] New: Add option to lit that prints intermediate commands, regardless or whether the test passed or failed

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

Bug ID: 30677
   Summary: Add option to lit that prints intermediate commands,
regardless or whether the test passed or failed
   Product: Test Suite
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: lit
  Assignee: unassignedb...@nondot.org
  Reporter: modoca...@gmail.com
CC: dan...@zuster.org, llvm-bugs@lists.llvm.org
Classification: Unclassified

LLVM and Swift developers frequently add `RUN: false` to their shell tests in
order to have lit stop execution and print the commands lit has run. This is
because lit only prints the commands it executed when the test fails.

Add an option to lit that prints these commands regardless of whether the test
passes. For example, it could look something like this:

lit -v --print-commands /path/to/tests
SCRIPT: tests :: test-one.py Script:
--
rm -rf /path/to/tests/Output
mkdir -p /path/to/tests/Output
python /path/to/tests/test.py > /path/to/tests/Output/out.txt
FileCheck < /path/to/tests/Output/out.txt /path/to/tests/test-one.py
---
PASS: tests :: test-one.py (1 of 1)

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

[llvm-bugs] [Bug 30678] New: [GCOV] Crashes when trying to compile a simple cpp file

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

Bug ID: 30678
   Summary: [GCOV] Crashes when trying to compile a simple cpp
file
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: hxy9...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17427
  --> https://llvm.org/bugs/attachment.cgi?id=17427&action=edit
Debug script generated from clang.

As of trunk on Oct. 11, the x86_64 LLVM compiler is still crashing when trying
to compile with the GCOV option. The following is the clang backtrace output.

Attached is the slightly modified debug shell and preprocessed cpp from clang.


---

clang -cc1 version 4.0.0 based upon LLVM 4.0.0svn default target
x86_64-unknown-linux-gnu
#include "..." search starts here:
End of search list.
clang-4.0: /tmp/tmp.6qQhiGb7vv/llvm/lib/Support/raw_ostream.cpp:525: virtual
size_t llvm::raw_fd_ostream::preferred_buffer_size() const: Assertion `FD >= 0
&& "File not yet open!"' failed.
#0 0x7f3594c2e235 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xde235)
#1 0x7f3594c2bf8e llvm::sys::RunSignalHandlers()
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xdbf8e)
#2 0x7f3594c2c0f2 SignalHandler(int)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xdc0f2)
#3 0x7f3598113330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x7f3592adfc37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7f3592ae3028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7f3592ad8bf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#7 0x7f3592ad8ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#8 0x7f3594c0e21e
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xbe21e)
#9 0x7f3594c0e53f llvm::raw_ostream::SetBuffered()
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xbe53f)
#10 0x7f3594c0ecd3 llvm::raw_ostream::write(char const*, unsigned long)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMSupport.so.40+0xbecd3)
#11 0x7f35987b0bd6 (anonymous namespace)::GCOVProfiler::emitProfileNotes()
[clone .constprop.327]
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMInstrumentation.so.40+0x47bd6)
#12 0x7f35987b2118 (anonymous
namespace)::GCOVProfilerLegacyPass::runOnModule(llvm::Module&)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMInstrumentation.so.40+0x49118)
#13 0x7f3595feda8d llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libLLVMCore.so.40+0x163a8d)
#14 0x7f359761fe07 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangCodeGen.so.40+0x77e07)
#15 0x7f35977dc30e
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangCodeGen.so.40+0x23430e)
#16 0x7f358ff99238 clang::ParseAST(clang::Sema&, bool, bool)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/../lib/libclangParse.so.40+0x2c238)
#17 0x7f35977d7ac7 clang::CodeGenAction::ExecuteAction()
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangCodeGen.so.40+0x22fac7)
#18 0x7f3596fc8fa6 clang::FrontendAction::Execute()
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangFrontend.so.40+0xb2fa6)
#19 0x7f3596f920f6
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangFrontend.so.40+0x7c0f6)
#20 0x7f3596d148bb
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/sarc-c/compiler_tmp/tools/cross/llvm-4.0/2016-10-11-23-30-38-80cf341-master/bin/../lib/libclangFrontendTool.so.40+0x38bb)
#21 0x0040ff28 cc1_main(llvm::ArrayRef, char const*,
void*)
(/sarc-c/compiler_tmp/tools/c

[llvm-bugs] [Bug 30679] New: scan-build did not found error on simple program with assert()

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

Bug ID: 30679
   Summary: scan-build did not found error on simple program with
assert()
   Product: clang
   Version: 3.8
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Static Analyzer
  Assignee: kreme...@apple.com
  Reporter: socketp...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

#include 
#include 

static void show(const char *const msg)
{
assert(msg != NULL);
printf("msg=%s\n", msg);
}

int main(void)
{
show("qwe");
show(NULL);
show("asd");
return 0;
}

==

scan-build finds no error in this code. But finds other errors (like possibly
memory leakage when I explicitly add such error in the code.

=

scan-build-3.8 gcc qwe.c
scan-build: Using '/usr/lib/llvm-3.8/bin/clang' for static analysis
scan-build: Removing directory '/tmp/scan-build-2016-10-13-37-5639-1'
because it contains no reports.
scan-build: No bugs found.

=

qwe.i: (no difference  on gcc and clang except whitespaces)

...

(!)!! note __noreturn__ and http://clang-analyzer.llvm.org/annotations.html
!

# 69 "/usr/include/assert.h" 3 4
extern void __assert_fail (const char *__assertion, const char *__file,
  unsigned int __line, const char *__function)
 __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));

...

static void show(const char *const msg)
{
   ((msg != ((void *)0)) ? (void) (0) : __assert_fail ("msg != NULL", "qwe.c",
7, __PRETTY_FUNCTION__))

printf("msg=%s\n", msg);
}

...

=

-- 
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 30665] lld confuses object files with the same name, but from different archive files in lto mode

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

Davide Italiano  changed:

   What|Removed |Added

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

--- Comment #4 from Davide Italiano  ---
Ivan, p[ease try r284034.
Thanks!

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

[llvm-bugs] [Bug 30679] scan-build did not found error on simple program with assert()

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

Devin Coughlin  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 30680] New: lld + LTO: symbol __start_($SECTION_NAME) is missing type

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

Bug ID: 30680
   Summary: lld + LTO: symbol __start_($SECTION_NAME) is missing
type
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: kra...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17429
  --> https://llvm.org/bugs/attachment.cgi?id=17429&action=edit
the reproducer

Consider the following shared object (the full reproducer is attached):

bar.cc:

__attribute((visibility("default"))) __attribute__ ((section("play_go")))
void* get_start();

extern "C" char __start_play_go[] __attribute__((weak));

void* get_start() {
  return reinterpret_cast(__start_play_go);
}

Basically, we put get_start function into play_go section and also use
__start_play_go symbol to keep it there.

Then we try to use this symbol from main.cc

#include 

extern "C" char __start_play_go[] __attribute__((weak));

int main(void) {
  printf("__start_play_go: %p\n", __start_play_go);
}

Building:

$ clang++ -shared -o libbar.so bar.cc
$ clang++ -c main.cc -flto
$ clang++ -o sections main.o libbar.so -flto -fuse-ld=lld
symbol __start_play_go is missing type
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)

I observe that while building Chromium, as tcmalloc uses this dark magic of
sections for hooks.

-- 
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 30663] Crash in PowerPC MI Peephole Optimization

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

Tim Shen  changed:

   What|Removed |Added

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

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

[llvm-bugs] [Bug 30681] New: [crash] add-discriminators pass handles inlined locations incorrectly

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

Bug ID: 30681
   Summary: [crash] add-discriminators pass handles inlined
locations incorrectly
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Transformation Utilities
  Assignee: unassignedb...@nondot.org
  Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17430
  --> https://llvm.org/bugs/attachment.cgi?id=17430&action=edit
t.ll

In the following example the add-discriminators pass is incorrectly setting the
scope of a non-inlined instruction (br) to the scope of its inlined predecessor
(%call.i).
This causes the LLVM Verifier to fail and assertions to fire.

To reproduce run:
clang-4.0 -cc1 -emit-obj  -disable-llvm-optzns t.ll -o /dev/null -mllvm
-debug-only=add-discriminators
warning: overriding the module target triple with x86_64-apple-darwin16.1.0
t.c:1:27:1  %call.i = tail call i8* @__memset_chk(i8* null, i32 0, i64 0, i64
%0) #2, !dbg !19
t.c:1:9:1  br label %for.cond, !dbg !21, !llvm.loop !22
!dbg attachment points at wrong subprogram for function
!7 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 1, type: !8,
isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0,
variables: !2)
i32 ()* @f
  br label %for.cond, !dbg !21, !llvm.loop !22
!21 = !DILocation(line: 1, column: 9, scope: !20)
!20 = !DILexicalBlockFile(scope: !12, file: !1, discriminator: 1)
!12 = distinct !DISubprogram(name: "g", scope: !1, file: !1, line: 1, type: !8,
isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0,
variables: !2)
!dbg attachment points at wrong subprogram for function
!7 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 1, type: !8,
isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0,
variables: !2)
i32 ()* @f
  br label %for.cond, !dbg !21, !llvm.loop !22
!21 = !DILocation(line: 1, column: 9, scope: !20)
!20 = !DILexicalBlockFile(scope: !12, file: !1, discriminator: 1)
!12 = distinct !DISubprogram(name: "g", scope: !1, file: !1, line: 1, type: !8,
isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: true, unit: !0,
variables: !2)
Assertion failed: (cast(Scope)->describes(MF->getFunction())),
function getOrCreateRegularScope, file ../lib/CodeGen/LexicalScopes.cpp, line
159.
Stack dump:
0.Program arguments:
/Volumes/Fusion/Data/llvm/_build.ninja.release/bin/clang-4.0 -cc1 -emit-obj
-disable-llvm-optzns t.ll -o /dev/null -mllvm -debug-only=add-discriminators 
1.Code generation
2.Running pass 'Function Pass Manager' on module 't.ll'.
3.Running pass 'Live DEBUG_VALUE analysis' on function '@f'
Abort trap: 6

-- 
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 30682] New: Bogus .loc directive with -mavx

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

Bug ID: 30682
   Summary: Bogus .loc directive with -mavx
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: paul_robin...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

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

Compiling the attached test case for X64 Linux as
   clang -c -g -S bz159663-min.cpp -mno-avx -o okay.s
and
   clang -c -g -S bz159663-min.cpp -mavx -o bad.s
and diffing the results, we see the obvious instruction differences
but also 'bad.s' has some weird stuff going on with the .loc directives.
Here's an extract from a diff, showing the assembler text generated
for source line 11 (the call to method setY):

***
  .loc1 11 33 is_stmt 1   # bz159663-min.cpp:11:33
  movl-12(%rbp), %ecx
  .loc1 11 45 is_stmt 0   # bz159663-min.cpp:11:45
  movb%ch, %dl  # NOREX
  movzbl%dl, %ecx  # NOREX
  .loc1 11 32 # bz159663-min.cpp:11:32
! cvtsi2ssl%ecx, %xmm0
! .loc1 11 8  # bz159663-min.cpp:11:8
  movq-24(%rbp), %rdi # 8-byte Reload
  callq_ZN7Vector44setYEf
---
  .loc1 11 33 is_stmt 1   # bz159663-min.cpp:11:33
  movl-12(%rbp), %ecx
  .loc1 11 45 is_stmt 0   # bz159663-min.cpp:11:45
  movb%ch, %dl  # NOREX
  movzbl%dl, %ecx  # NOREX
+ .loc1 10 32 is_stmt 1   # bz159663-min.cpp:10:32
+ # implicit-def: %XMM0
  .loc1 11 32 # bz159663-min.cpp:11:32
! vcvtsi2ssl%ecx, %xmm0, %xmm0
! .loc1 11 8 is_stmt 0# bz159663-min.cpp:11:8
  movq-24(%rbp), %rdi # 8-byte Reload
  callq_ZN7Vector44setYEf
***

What is it about AVX that introduces the spurious directive?

-- 
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 30499] UNREACHABLE executed at ../include/llvm/Analysis/MemoryLocation.h:81

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

Reid Kleckner  changed:

   What|Removed |Added

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

--- Comment #7 from Reid Kleckner  ---
Literally the same test case crashes clang with r283965, reverting.

-- 
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 29022] x86_64 backend sometimes generates 'leaq (%rsp), %x' rather than 'movq %rsp, %x'

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

Michael Kuperstein  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Kuperstein  ---
Sure.

-- 
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 26168] COFF writer does not correctly implement private linkage

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

Reid Kleckner  changed:

   What|Removed |Added

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

--- Comment #3 from Reid Kleckner  ---
Thanks for the patch, r284096

-- 
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 27898] MC includes COFF symbols starting with L in the output

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

Reid Kleckner  changed:

   What|Removed |Added

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

--- Comment #3 from Reid Kleckner  ---
Applied in r284096, thanks!

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

[llvm-bugs] [Bug 30499] UNREACHABLE executed at ../include/llvm/Analysis/MemoryLocation.h:81

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #8 from Sebastian Pop  ---
Fixed in r284098.

-- 
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 30683] New: bart 0.3.0 causes clang 3.8-4.0: error: Segmentation fault

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

Bug ID: 30683
   Summary: bart 0.3.0 causes clang 3.8-4.0: error: Segmentation
fault
   Product: new-bugs
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: lukebe...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17434
  --> https://llvm.org/bugs/attachment.cgi?id=17434&action=edit
Reproducer from /tmp

Steps to reproduce:
1. Download bart-v0.3.00.zip
https://zenodo.org/record/44511
2. unzip
3. make with Clang 3.8 to 4.0(trunk 283963)

Expect Result:
Compile without error like gcc

Actual Result:

clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0 (trunk 283963)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-4.0: note: diagnostic msg: 


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

This issue was also discovered by the Debian 3.8 clang project:
http://clang.debian.net/logs/2016-08-30/bart_0.3.00-1_unstable_clang.log

-- 
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 30684] New: wreport causes clang 3.8-4.0: error: Segmentation fault

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

Bug ID: 30684
   Summary: wreport causes clang 3.8-4.0: error: Segmentation
fault
   Product: new-bugs
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: lukebe...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17437
  --> https://llvm.org/bugs/attachment.cgi?id=17437&action=edit
Reproducer from /tmp

Steps to reproduce:
1. git clone https://github.com/ARPA-SIMC/wreport.git
2. autoreconf -if 
3. ./configure
4. make

Expected result:
gcc builds without any problems

Actual Result:
1.tests.cc:279:39: current parser token ';'
2.tests.cc:33:1: parsing namespace 'wreport'
3.tests.cc:34:1: parsing namespace 'wreport::tests'
4.../wreport/tests.h:77:59: instantiating function definition
'wreport::tests::TestCodec::(anonymous
class)::operator()'
5.../wreport/tests.h:77:59: LLVM IR generation of declaration
'wreport::tests::TestCodec::(anonymous
class)::operator()'
6.../wreport/tests.h:77:59: Generating code for declaration
'wreport::tests::TestCodec::(anonymous
class)::operator()'
clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0 (trunk 283963)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-4.0: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /tmp/tests-489137.cpp
clang-4.0: note: diagnostic msg: /tmp/tests-489137.sh

This was with clang version 4.0.0 (trunk 283963)

The Debian Clang Rebuild similar results with Clang 3.8
http://clang.debian.net/logs/2016-08-30/wreport_3.6-1_unstable_clang.log

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