Skip to content

[SYCL][CUDA] Removing unnecessary tool from the tree #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Feb 11, 2020
Merged

[SYCL][CUDA] Removing unnecessary tool from the tree #2

merged 1 commit into from
Feb 11, 2020

Conversation

Ruyk
Copy link
Contributor

@Ruyk Ruyk commented Feb 10, 2020

No description provided.

@Naghasan Naghasan force-pushed the Ruyk/remove-unnecessary-tool branch from 4dbf6af to 6e6996c Compare February 10, 2020 15:49
@Naghasan Naghasan merged this pull request into cuda Feb 11, 2020
codeplay-sycl pushed a commit that referenced this pull request Feb 11, 2020
Merge from 'sycl' to 'sycl-web' (#2)
ccb4b0f
codeplay-sycl pushed a commit that referenced this pull request Feb 11, 2020
Merge from 'sycl' to 'sycl-web' (#2)
b59a104
codeplay-sycl pushed a commit that referenced this pull request Feb 18, 2020
Merge from 'sycl' to 'sycl-web' (#2)
23fd3a0
codeplay-sycl pushed a commit that referenced this pull request Feb 18, 2020
@bader
Merge from 'master' to 'sycl-web' (#2)
8c779b7 
  CONFLICT (content): Merge conflict in clang/lib/Sema/Sema.cpp
codeplay-sycl pushed a commit that referenced this pull request Feb 26, 2020
@bader
Merge from 'master' to 'sycl-web' (#2)
34dd7d2 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaChecking.cpp
codeplay-sycl pushed a commit that referenced this pull request Feb 26, 2020
Merge from 'sycl' to 'sycl-web' (#2)
bd3a8ee
codeplay-sycl pushed a commit that referenced this pull request Feb 26, 2020
@bader
Merge from 'master' to 'sycl-web' (#2)
ee9ee55 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaChecking.cpp
codeplay-sycl pushed a commit that referenced this pull request Mar 9, 2020
Recommit #2 "[Driver] Default to -fno-common for all targets"
3d9a044 
After a first attempt to fix the test-suite failures, my first recommit
caused the same failures again. I had updated CMakeList.txt files of
tests that needed -fcommon, but it turns out that there are also
Makefiles which are used by some bots, so I've updated these Makefiles
now too.

See the original commit message for more details on this change:
0a9fc92
codeplay-sycl pushed a commit that referenced this pull request Mar 12, 2020
@dylanmckay
Revert "[AVR] Include AVR by default in LLVM builds"
9059056 
This reverts commit dfecec6.

Merging the change revealed that there is a failure on the memory
sanitizer bots.

    Command Output (stderr):
    --
    ==3569==WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x1d71bff in
           llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
        #1 0x1d721f8 in initializeSubtargetDependencies
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:50:3
        #2 0x1d721f8 in llvm::AVRSubtarget::AVRSubtarget(llvm::Triple
           const&, std::__1::basic_string<char, std::__1::char_traits<char>,
    std::__1::allocator<char> > const&, std::__1::basic_string<char,
    std::__1::char_traits<char>, std::__1::allocator<char> > const&,
    llvm::AVRTargetMachine const&)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:33:18
        #3 0x1d3077f in
           llvm::AVRTargetMachine::AVRTargetMachine(llvm::Target const&,
    llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRTargetMachine.cpp:52:7
        #4 0x1d3169d in
           llvm::RegisterTargetMachine<llvm::AVRTargetMachine>::Allocator(llvm::Target
    const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:1121:16
        #5 0x86662f in createTargetMachine
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:402:12
        #6 0x86662f in compileModule(char**, llvm::LLVMContext&)
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:473:52
        #7 0x861f42 in main
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:356:22
        #8 0x7f76f7b072e0 in __libc_start_main
           (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
        #9 0x7ebbc9 in _start
           (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x7ebbc9)

    SUMMARY: MemorySanitizer: use-of-uninitialized-value
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
    in llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    Exiting
    FileCheck error: '<stdin>' is empty.
    --

The patch wiill be re-committed once fixed.
codeplay-sycl pushed a commit that referenced this pull request Mar 14, 2020
[AArch64][Fix] LdSt optimization generate premature stack-popping
83cdb65 
Summary:
When moving add and sub to memory operand instructions,
aarch64-ldst-opt would prematurally pop the stack pointer,
before memory instructions that do access the stack using
indirect loads.
e.g.
```
int foo(int offset){
    int local[4] = {0};
    return local[offset];
}
```
would generate:
```
sub     sp, sp, #16            ; Push the stack
mov     x8, sp                 ; Save stack in register
stp     xzr, xzr, [sp], #16    ; Zero initialize stack, and post-increment, making it invalid
------ If an exception goes here, the stack value might be corrupted
ldr     w0, [x8, w0, sxtw #2]  ; Access correct position, but it is not guarded by SP
```

Reviewers: fhahn, foad, thegameg, eli.friedman, efriedma

Reviewed By: efriedma

Subscribers: efriedma, kristof.beyls, hiraditya, danielkiss, llvm-commits, simon_tatham

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75755
codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020
Merge from 'sycl' to 'sycl-web' (#2)
90f7a34
codeplay-sycl pushed a commit that referenced this pull request Apr 2, 2020
@bader
Merge from 'master' to 'sycl-web' (#2)
e4d1da9 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaDecl.cpp
  CONFLICT (content): Merge conflict in clang/lib/Sema/Sema.cpp
codeplay-sycl pushed a commit that referenced this pull request Apr 6, 2020
@rnk
[AST] Remove DeclCXX.h dep on ASTContext.h
b36c19b 
Saves only 36 includes of ASTContext.h and related headers.

There are two deps on ASTContext.h:
- C++ method overrides iterator types (TinyPtrVector)
- getting LangOptions

For #1, duplicate the iterator type, which is
TinyPtrVector<>::const_iterator.

For #2, add an out-of-line accessor to get the language options. Getting
the ASTContext from a Decl is already an out of line method that loops
over the parent DeclContexts, so if it is ever performance critical, the
proper fix is to pass the context (or LangOpts) into the predicate in
question.

Other changes are just header fixups.
codeplay-sycl pushed a commit that referenced this pull request Apr 13, 2020
@delcypher
[Darwin] Fix a bug where the symbolizer would examine the wrong process.
8efc3cc 
Summary:
Previously `AtosSymbolizer` would set the PID to examine in the
constructor which is called early on during sanitizer init. This can
lead to incorrect behaviour in the case of a fork() because if the
symbolizer is launched in the child it will be told examine the parent
process rather than the child.

To fix this the PID is determined just before the symbolizer is
launched.

A test case is included that triggers the buggy behaviour that existed
prior to this patch. The test observes the PID that `atos` was called
on. It also examines the symbolized stacktrace. Prior to this patch
`atos` failed to symbolize the stacktrace giving output that looked
like...

```
  #0 0x100fc3bb5 in __sanitizer_print_stack_trace asan_stack.cpp:86
  #1 0x10490dd36 in PrintStack+0x56 (/path/to/print-stack-trace-in-code-loaded-after-fork.cpp.tmp_shared_lib.dylib:x86_64+0xd36)
  #2 0x100f6f986 in main+0x4a6 (/path/to/print-stack-trace-in-code-loaded-after-fork.cpp.tmp_loader:x86_64+0x100001986)
  #3 0x7fff714f1cc8 in start+0x0 (/usr/lib/system/libdyld.dylib:x86_64+0x1acc8)
```

After this patch stackframes `#1` and `#2` are fully symbolized.

This patch is also a pre-requisite refactor for rdar://problem/58789439.

Reviewers: kubamracek, yln

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D77623
codeplay-sycl pushed a commit that referenced this pull request Apr 15, 2020
@hokein
[AST] Fix recovery-expr crash on invalid aligned attr.
17198df 
Summary:
crash stack:

```
lang: tools/clang/include/clang/AST/AttrImpl.inc:1490: unsigned int clang::AlignedAttr::getAlignment(clang::ASTContext &) const: Assertion `!isAlignmentDependent()' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: ./bin/clang -cc1 -std=c++1y -ast-dump -frecovery-ast -fcxx-exceptions /tmp/t4.cpp
1.      /tmp/t4.cpp:3:31: current parser token ';'
 #0 0x0000000002530cff llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
 #1 0x000000000252ee30 llvm::sys::RunSignalHandlers() llvm-project/llvm/lib/Support/Signals.cpp:69:18
 #2 0x000000000253126c SignalHandler(int) llvm-project/llvm/lib/Support/Unix/Signals.inc:396:3
 #3 0x00007f86964d0520 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13520)
 #4 0x00007f8695f9ff61 raise /build/glibc-oCLvUT/glibc-2.29/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x00007f8695f8b535 abort /build/glibc-oCLvUT/glibc-2.29/stdlib/abort.c:81:7
 #6 0x00007f8695f8b40f _nl_load_domain /build/glibc-oCLvUT/glibc-2.29/intl/loadmsgcat.c:1177:9
 #7 0x00007f8695f98b92 (/lib/x86_64-linux-gnu/libc.so.6+0x32b92)
 #8 0x0000000004503d9f llvm::APInt::getZExtValue() const llvm-project/llvm/include/llvm/ADT/APInt.h:1623:5
 #9 0x0000000004503d9f clang::AlignedAttr::getAlignment(clang::ASTContext&) const llvm-project/build/tools/clang/include/clang/AST/AttrImpl.inc:1492:0
```

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78085
codeplay-sycl pushed a commit that referenced this pull request Apr 16, 2020
@dmpolukhin
Revert "[clang][AST] Support AST files larger than 512M"
a8f85da 
Bitcode file alignment is only 32-bit so 64-bit offsets need
special handling.
/b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:6327:28: runtime error: load of misaligned address 0x7fca2bcfe54c for type 'const uint64_t' (aka 'const unsigned long'), which requires 8 byte alignment
0x7fca2bcfe54c: note: pointer points here
  00 00 00 00 5a a6 01 00  00 00 00 00 19 a7 01 00  00 00 00 00 48 a7 01 00  00 00 00 00 7d a7 01 00
              ^
    #0 0x3be2fe4 in clang::ASTReader::TypeCursorForIndex(unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:6327:28
    #1 0x3be30a0 in clang::ASTReader::readTypeRecord(unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:6348:24
    #2 0x3bd3d4a in clang::ASTReader::GetType(unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:6985:26
    #3 0x3c5d9ae in clang::ASTDeclReader::Visit(clang::Decl*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp:533:31
    #4 0x3c91cac in clang::ASTReader::ReadDeclRecord(unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp:4045:10
    #5 0x3bd4fb1 in clang::ASTReader::GetDecl(unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:7352:5
    #6 0x3bce2f9 in clang::ASTReader::ReadASTBlock(clang::serialization::ModuleFile&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:3625:22
    #7 0x3bd6d75 in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule>*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:4230:32
    #8 0x3a6b415 in clang::CompilerInstance::createPCHExternalASTSource(llvm::StringRef, llvm::StringRef, bool, bool, clang::Preprocessor&, clang::InMemoryModuleCache&, clang::ASTContext&, clang::PCHContainerReader const&, llvm::ArrayRef<std::shared_ptr<clang::ModuleFileExtension> >, llvm::ArrayRef<std::shared_ptr<clang::DependencyCollector> >, void*, bool, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:539:19
    #9 0x3a6b00e in clang::CompilerInstance::createPCHExternalASTSource(llvm::StringRef, bool, bool, void*, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:501:18
    #10 0x3abac80 in clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:865:12
    #11 0x3a6e61c in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:972:13
    #12 0x3ba74bf in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:282:25
    #13 0xa3f753 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/cc1_main.cpp:240:15
    #14 0xa3a68a in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:330:12
    #15 0xa37f31 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:407:12
    #16 0x7fca2a7032e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #17 0xa21029 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_ubsan/bin/clang-11+0xa21029)

This reverts commit 30d5946.
codeplay-sycl pushed a commit that referenced this pull request Apr 27, 2020
@Teemperor
[lldb] Adjust TestExec code to be closer to real world code
d00eaa0 
Summary:
For some reason the TestExec test on the macOS bots randomly fails with this error:
```
output: * thread #2, stop reason = EXC_BAD_ACCESS (code=1, address=0x108e66000)
  * frame #0: 0x0000000108e66000
[...]
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py", line 25, in test_hitting_exec
    self.do_test(False)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py", line 113, in do_test
    "Stopped at breakpoint in exec'ed process.")
AssertionError: False is not True : Stopped at breakpoint in exec'ed process.
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-11
```

I don't know why the test program is failing and I couldn't reproduce this problem on my own.
This patch is a stab in the dark that just tries to make the test code more similar to code which
we would expect in a user program to make whatever part of macOS happy that is currently
not liking our code.

The actual changes are:
* We pass in argv[0] that is describing otherprog path instead of the current argv[0].
* We pass in a non-null envp (which anyway doesn't seem to be allowed on macOS man page).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D75241
codeplay-sycl pushed a commit that referenced this pull request May 6, 2020
@thejh @ramosian-glider
[AddressSanitizer] Instrument byval call arguments
a226858 
Summary:
In the LLVM IR, "call" instructions read memory for each byval operand.
For example:

```
$ cat blah.c
struct foo { void *a, *b, *c; };
struct bar { struct foo foo; };
void func1(const struct foo);
void func2(struct bar *bar) { func1(bar->foo); }
$ [...]/bin/clang -S -flto -c blah.c -O2 ; cat blah.s
[...]
define dso_local void @func2(%struct.bar* %bar) local_unnamed_addr #0 {
entry:
  %foo = getelementptr inbounds %struct.bar, %struct.bar* %bar, i64 0, i32 0
  tail call void @func1(%struct.foo* byval(%struct.foo) align 8 %foo) #2
  ret void
}
[...]
$ [...]/bin/clang -S -c blah.c -O2 ; cat blah.s
[...]
func2:                                  # @func2
[...]
        subq    $24, %rsp
[...]
        movq    16(%rdi), %rax
        movq    %rax, 16(%rsp)
        movups  (%rdi), %xmm0
        movups  %xmm0, (%rsp)
        callq   func1
        addq    $24, %rsp
[...]
        retq
```

Let ASAN instrument these hidden memory accesses.

This is patch 4/4 of a patch series:
https://reviews.llvm.org/D77616 [PATCH 1/4] [AddressSanitizer] Refactor ClDebug{Min,Max} handling
https://reviews.llvm.org/D77617 [PATCH 2/4] [AddressSanitizer] Split out memory intrinsic handling
https://reviews.llvm.org/D77618 [PATCH 3/4] [AddressSanitizer] Refactor: Permit >1 interesting operands per instruction
https://reviews.llvm.org/D77619 [PATCH 4/4] [AddressSanitizer] Instrument byval call arguments

Reviewers: kcc, glider

Reviewed By: glider

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77619
codeplay-sycl pushed a commit that referenced this pull request May 8, 2020
@bader
Merge from 'master' to 'sycl-web' (#2)
d521eaf 
  CONFLICT (content): Merge conflict in clang/include/clang/Basic/LangOptions.h
codeplay-sycl pushed a commit that referenced this pull request May 8, 2020
@abhinavgaba
Merge from 'master' to 'sycl-web' (#2)
e17e513 
  CONFLICT (content): Merge conflict in clang/lib/AST/DeclPrinter.cpp
codeplay-sycl pushed a commit that referenced this pull request May 8, 2020
@abhinavgaba
Merge from 'master' to 'sycl-web' (#2)
918d599 
  CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGCall.cpp
codeplay-sycl pushed a commit that referenced this pull request Sep 29, 2020
Merge from 'sycl' to 'sycl-web' (#2)
c717933
codeplay-sycl pushed a commit that referenced this pull request Sep 30, 2020
@rorth
[sanitizers] Fix internal__exit on Solaris
dc261d2 
`TestCases/log-path_test.cpp` currently `FAIL`s on Solaris:

  $ env ASAN_OPTIONS=log_path=`for((i=0;i<10000;i++)); do echo -n $i; done`  ./log-path_test.cpp.tmp
  ==5031==ERROR: Path is too long: 01234567...
  Segmentation Fault (core dumped)

The `SEGV` happens here:

  Thread 2 received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 1 (LWP 1)]
  0x00000000 in ?? ()
  (gdb) where
  #0  0x00000000 in ?? ()
  #1  0x080a1e63 in __interceptor__exit (status=1)
      at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3808
  #2  0x08135ea8 in __sanitizer::internal__exit (exitcode=1)
      at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/sanitizer_solaris.cc:139

when `__interceptor__exit` tries to call `__interception::real__exit` which
is `NULL` at this point because the interceptors haven't been initialized yet.

Ultimately, the problem lies elsewhere, however: `internal__exit` in
`sanitizer_solaris.cpp` calls `_exit` itself since there doesn't exit a
non-intercepted version in `libc`.  Using the `syscall` interface instead
isn't usually an option on Solaris because that interface isn't stable.
However, in the case of `SYS_exit` it can be used nonetheless: `SYS_exit`
has remained unchanged since at least Solaris 2.5.1 in 1996, and this is
what this patch does.

Tested on `amd64-pc-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D88404
codeplay-sycl pushed a commit that referenced this pull request Oct 9, 2020
Merge from 'master' to 'sycl-web' (#2)
cf4a898 
  CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticDriverKinds.td
codeplay-sycl pushed a commit that referenced this pull request Oct 9, 2020
@robertcox-github
Merge from 'master' to 'sycl-web' (#2)
46977c4 
  CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticDriverKinds.td
codeplay-sycl pushed a commit that referenced this pull request Oct 13, 2020
@ruiling
[AMDGPU] Update LiveVariables in convertToThreeAddress()
b215a26 
This can fix an asan failure like below.
==15856==ERROR: AddressSanitizer: use-after-poison on address ...
READ of size 8 at 0x6210001a3cb0 thread T0
    #0 llvm::MachineInstr::getParent()
    #1 llvm::LiveVariables::VarInfo::findKill()
    #2 TwoAddressInstructionPass::rescheduleMIBelowKill()
    #3 TwoAddressInstructionPass::tryInstructionTransform()
    #4 TwoAddressInstructionPass::runOnMachineFunction()

We need to update the Kills if we replace instructions. The Kills
may be later accessed within TwoAddressInstruction pass.

Differential Revision: https://reviews.llvm.org/D89092
codeplay-sycl pushed a commit that referenced this pull request Oct 28, 2020
@aelovikov-intel
Merge from 'master' to 'sycl-web' (#2)
b05ef6d 
  CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/MSVC.cpp
codeplay-sycl pushed a commit that referenced this pull request Oct 28, 2020
@vmaksimo
Merge from 'master' to 'sycl-web' (#2)
5a64d6b 
  CONFLICT (content): Merge conflict in README.md
codeplay-sycl pushed a commit that referenced this pull request Oct 28, 2020
Merge from 'sycl' to 'sycl-web' (#2)
c08fb65
codeplay-sycl pushed a commit that referenced this pull request Nov 3, 2020
@jrtc27
[RISCV] Only return DestSourcePair from isCopyInstrImpl for registers
7601a21 
ADDI often has a frameindex in operand 1, but consumers of this
interface, such as MachineSink, tend to call getReg() on the Destination
and Source operands, leading to the following crash when building
FreeBSD after this implementation was added in 8cf6778:

```
clang: llvm/include/llvm/CodeGen/MachineOperand.h:359: llvm::Register llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
 #0 0x00007f4286f9b4d0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) llvm/lib/Support/Unix/Signals.inc:563:0
 #1 0x00007f4286f9b587 PrintStackTraceSignalHandler(void*) llvm/lib/Support/Unix/Signals.inc:630:0
 #2 0x00007f4286f9926b llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:71:0
 #3 0x00007f4286f9ae52 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:405:0
 #4 0x00007f428646ffd0 (/lib/x86_64-linux-gnu/libc.so.6+0x3efd0)
 #5 0x00007f428646ff47 raise /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
 #6 0x00007f42864718b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0
 #7 0x00007f428646142a __assert_fail_base /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0
 #8 0x00007f42864614a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2)
 #9 0x00007f428d4078e2 llvm::MachineOperand::getReg() const llvm/include/llvm/CodeGen/MachineOperand.h:359:0
#10 0x00007f428d8260e7 attemptDebugCopyProp(llvm::MachineInstr&, llvm::MachineInstr&) llvm/lib/CodeGen/MachineSink.cpp:862:0
#11 0x00007f428d826442 performSink(llvm::MachineInstr&, llvm::MachineBasicBlock&, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>, llvm::SmallVectorImpl<llvm::MachineInstr*>&) llvm/lib/CodeGen/MachineSink.cpp:918:0
#12 0x00007f428d826e27 (anonymous namespace)::MachineSinking::SinkInstruction(llvm::MachineInstr&, bool&, std::map<llvm::MachineBasicBlock*, llvm::SmallVector<llvm::MachineBasicBlock*, 4u>, std::less<llvm::MachineBasicBlock*>, std::allocator<std::pair<llvm::MachineBasicBlock* const, llvm::SmallVector<llvm::MachineBasicBlock*, 4u> > > >&) llvm/lib/CodeGen/MachineSink.cpp:1073:0
#13 0x00007f428d824a2c (anonymous namespace)::MachineSinking::ProcessBlock(llvm::MachineBasicBlock&) llvm/lib/CodeGen/MachineSink.cpp:410:0
#14 0x00007f428d824513 (anonymous namespace)::MachineSinking::runOnMachineFunction(llvm::MachineFunction&) llvm/lib/CodeGen/MachineSink.cpp:340:0
```

Thus, check that operand 1 is also a register in the condition.

Reviewed By: arichardson, luismarques

Differential Revision: https://reviews.llvm.org/D89090
codeplay-sycl pushed a commit that referenced this pull request Nov 3, 2020
@vmaksimo
Merge from 'master' to 'sycl-web' (#2)
18eb83e 
  CONFLICT (content): Merge conflict in llvm/include/llvm/InitializePasses.h
codeplay-sycl pushed a commit that referenced this pull request Nov 11, 2020
[AArch64][GlobalISel] Select arith extended add/sub in manual selecti…
c42053f 
…on code

The manual selection code for add/sub was not checking if it was possible to
fold in shifts + extends (the *rx opcode variants).

As a result, we could never select things like

```
cmp x1, w0, uxtw #2
```

Because we don't import any patterns for compares.

This adds support for the arithmetic shifted register forms and updates tests
for instructions selected using `emitADD`, `emitADDS`, and `emitSUBS`.

This is a 0.1% geomean code size improvement on SPECINT2000 at -Os.

Differential Revision: https://reviews.llvm.org/D91207
codeplay-sycl pushed a commit that referenced this pull request Nov 16, 2020
@aemerson
[AArch64][GlobalISel] Look through a G_ZEXT when trying to match shif…
0b60906 
…t-extended register offsets.

The G_ZEXT in these cases seems to actually come from a combine that we do but
SelectionDAG doesn't. Looking through it allows us to match "uxtw #2" addressing
modes.

Differential Revision: https://reviews.llvm.org/D91475
codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020
@linkren
Merge from 'master' to 'sycl-web' (#2)
d0192a0 
  CONFLICT (content): Merge conflict in clang/utils/TableGen/TableGen.cpp
codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020
@linkren
Merge from 'sycl' to 'sycl-web' (#2)
f88df8c 
  CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td
codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020
Merge from 'sycl' to 'sycl-web' (#2)
12e4dc7
codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020
@aelovikov-intel
Merge from 'master' to 'sycl-web' (#2)
3999e42 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaDeclAttr.cpp
codeplay-sycl pushed a commit that referenced this pull request Nov 30, 2020
@rotateright
Revert "[IR][LoopRotate] avoid leaving phi with no operands (PR48296)"
355aee3 
This reverts commit bfd2c21.
This appears to be causing stage2 msan failures on buildbots:
  FAIL: LLVM :: Transforms/SimplifyCFG/X86/bug-25299.ll (65872 of 71835)
  ******************** TEST 'LLVM :: Transforms/SimplifyCFG/X86/bug-25299.ll' FAILED ********************
  Script:
  --
  : 'RUN: at line 1';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/opt < /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/Transforms/SimplifyCFG/X86/bug-25299.ll -simplifycfg -S | /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/FileCheck /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/Transforms/SimplifyCFG/X86/bug-25299.ll
  --
  Exit Code: 2
  Command Output (stderr):
  --
  ==87374==WARNING: MemorySanitizer: use-of-uninitialized-value
      #0 0x9de47b6 in getBasicBlockIndex /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/IR/Instructions.h:2749:5
      #1 0x9de47b6 in simplifyCommonResume /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:4112:23
      #2 0x9de47b6 in simplifyResume /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:4039:12
      #3 0x9de47b6 in (anonymous namespace)::SimplifyCFGOpt::simplifyOnce(llvm::BasicBlock*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6330:16
      #4 0x9dcca13 in run /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6358:16
      #5 0x9dcca13 in llvm::simplifyCFG(llvm::BasicBlock*, llvm::TargetTransformInfo const&, llvm::SimplifyCFGOptions const&, llvm::SmallPtrSetImpl<llvm::BasicBlock*>*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6369:8
      #6 0x974643d in iterativelySimplifyCFG(
codeplay-sycl pushed a commit that referenced this pull request Dec 1, 2020
@apolloww
[Remarks][2/2] Expand remarks hotness threshold option support in mor…
93dc1b5 
…e tools

This is the #2 of 2 changes that make remarks hotness threshold option
available in more tools. The changes also allow the threshold to sync with
hotness threshold from profile summary with special value 'auto'.

This change expands remarks hotness threshold option
-fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in
other tools to utilize hotness threshold from profile summary.

Remarks hotness filtering relies on several driver options. Table below lists
how different options are correlated and affect final remarks outputs:

| profile | hotness | threshold | remarks printed |
|---------|---------|-----------|-----------------|
| No      | No      | No        | All             |
| No      | No      | Yes       | None            |
| No      | Yes     | No        | All             |
| No      | Yes     | Yes       | None            |
| Yes     | No      | No        | All             |
| Yes     | No      | Yes       | None            |
| Yes     | Yes     | No        | All             |
| Yes     | Yes     | Yes       | >=threshold     |

In the presence of profile summary, it is often more desirable to directly use
the hotness threshold from profile summary. The new argument value 'auto'
indicates threshold will be synced with hotness threshold from profile summary
during compilation. The "auto" threshold relies on the availability of profile
summary. In case of missing such information, no remarks will be generated.

Differential Revision: https://reviews.llvm.org/D85808
codeplay-sycl pushed a commit that referenced this pull request Dec 9, 2020
[ASTImporter] Support CXXDeductionGuideDecl with local typedef
a5e6590 
CXXDeductionGuideDecl with a local typedef has its own copy of the
TypedefDecl with the CXXDeductionGuideDecl as the DeclContext of that
TypedefDecl.
```
      template <typename T> struct A {
        typedef T U;
        A(U, T);
      };
      A a{(int)0, (int)0};
```
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2020-November/067252.html

Without this fix, when we import the CXXDeductionGuideDecl (via
VisitFunctionDecl) then before creating the Decl we must import the
FunctionType. However, the first parameter's type is the afore mentioned
local typedef. So, we then start importing the TypedefDecl whose
DeclContext is the CXXDeductionGuideDecl itself. The infinite loop is
formed.
```
 #0 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
 #1 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:405:0
 #2 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
 #3 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
 #4 clang::ASTImporter::ImportContext(clang::DeclContext*) clang/lib/AST/ASTImporter.cpp:8297:0
 #5 clang::ASTNodeImporter::ImportDeclContext(clang::Decl*, clang::DeclContext*&, clang::DeclContext*&) clang/lib/AST/ASTImporter.cpp:1852:0
 #6 clang::ASTNodeImporter::ImportDeclParts(clang::NamedDecl*, clang::DeclContext*&, clang::DeclContext*&, clang::DeclarationName&, clang::NamedDecl*&, clang::SourceLocation&) clang/lib/AST/ASTImporter.cpp:1628:0
 #7 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) clang/lib/AST/ASTImporter.cpp:2419:0
 #8 clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) clang/lib/AST/ASTImporter.cpp:2500:0
 #9 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:315:0
 #10 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
 #11 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
 #12 llvm::Expected<clang::TypedefNameDecl*> clang::ASTNodeImporter::import<clang::TypedefNameDecl>(clang::TypedefNameDecl*) clang/lib/AST/ASTImporter.cpp:165:0
 #13 clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*) clang/lib/AST/ASTImporter.cpp:1304:0
 #14 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:74:0
 #15 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
 #16 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
 #17 clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*) clang/lib/AST/ASTImporter.cpp:1244:0
 #18 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:47:0
 #19 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
 #20 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
 #21 clang::QualType clang::ASTNodeImporter::importChecked<clang::QualType>(llvm::Error&, clang::QualType const&) clang/lib/AST/ASTImporter.cpp:198:0
 #22 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) clang/lib/AST/ASTImporter.cpp:3313:0
 #23 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
```

The fix is to first create the TypedefDecl and only then start to import
the DeclContext.
Basically, we could do this during the import of all other Decls (not
just for typedefs). But it seems, there is only one another AST
construct that has a similar cycle: a struct defined as a function
parameter:
```
int struct_in_proto(struct data_t{int a;int b;} *d);

```
In that case, however, we had decided to return simply with an error
back then because that seemed to be a very rare construct.

Differential Revision: https://reviews.llvm.org/D92209
codeplay-sycl pushed a commit that referenced this pull request Dec 22, 2020
@linkren
Merge from 'master' to 'sycl-web' (#2)
dee2ee9 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
codeplay-sycl pushed a commit that referenced this pull request Dec 25, 2020
@linkren
Merge from 'main' to 'sycl-web' (#2)
729a222 
  CONFLICT (content): Merge conflict in clang/lib/Frontend/CompilerInvocation.cpp
  CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td
codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021
@AlexeySachkov
Merge from 'main' to 'sycl-web' (#2)
1829b42 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaLookup.cpp
codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021
@ochupina
Merge from 'main' to 'sycl-web' (#2)
659b778 
  CONFLICT (content): Merge conflict in clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
  CONFLICT (content): Merge conflict in clang/test/Driver/clang-offload-bundler.c
codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021
Merge from 'sycl' to 'sycl-web' (#2)
23cab0b
codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021
@ochupina
Merge from 'main' to 'sycl-web' (#2)
ed6b605 
  CONFLICT (content): Merge conflict in clang/lib/Frontend/CompilerInvocation.cpp
  CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td
codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021
@AlexeySachkov
Merge from 'main' to 'sycl-web' (#2)
74e62f0 
  CONFLICT (content): Merge conflict in clang/lib/Sema/SemaDecl.cpp
codeplay-sycl pushed a commit that referenced this pull request Jan 22, 2021
@akyrtzi
[ASTReader] Allow controlling separately whether validation should be…
b0e8990 
… disabled for a PCH vs a module file

This addresses an issue with how the PCH preable works, specifically:

1. When using a PCH/preamble the module hash changes and a different cache directory is used
2. When the preamble is used, PCH & PCM validation is disabled.

Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date.

rdar://72611253

Differential Revision: https://reviews.llvm.org/D95159
codeplay-sycl pushed a commit that referenced this pull request Jan 28, 2021
Merge from 'sycl' to 'sycl-web' (#2)
9f4c5ca
codeplay-sycl pushed a commit that referenced this pull request Jan 28, 2021
@AlexeySachkov
Merge from 'main' to 'sycl-web' (#2)
2f8ebfe 
  CONFLICT (content): Merge conflict in clang/include/clang/Basic/Attr.td
codeplay-sycl pushed a commit that referenced this pull request Feb 5, 2021
@dm-vodopyanov
Merge from 'sycl' to 'sycl-web' (#2)
6234a2e 
  CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Naghasan Naghasan Naghasan approved these changes

@Alexander-Johnston Alexander-Johnston Alexander-Johnston approved these changes

Assignees

@Ruyk Ruyk

@Naghasan Naghasan

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Ruyk @Naghasan @Alexander-Johnston