summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Rename MemoryBufferCache to InMemoryModuleCacheDuncan P. N. Exon Smith2019-03-092-48/+0
| | | | | | | | | | | | | Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-081-11/+12
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355685
* Rollback of rL355585.Mitch Phillips2019-03-071-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots: ``` ================================================================= ==2453==ERROR: LeakSanitizer: detected memory leaks Direct leak of 128 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19 #2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12 #3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) Indirect leak of 40 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29 #2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241 #3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16 #4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s). ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information. Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr: ``` ==7070==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 #1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44 #2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78 #3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9 #4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314 #5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18 #6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49) SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information. llvm-svn: 355616
* [OPENMP 5.0]Add initial support for 'allocate' directive.Alexey Bataev2019-03-071-0/+6
| | | | | | | Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
* [libclang] Fix CXTranslationUnit_KeepGoingIvan Donchevskii2019-03-071-1/+6
| | | | | | | | | | | | | | | | | | Since commit 56f548bbbb7e4387a69708f70724d00e9e076153 [modules] Round-trip -Werror flag through explicit module build. the behavior of CXTranslationUnit_KeepGoing changed: Unresolved #includes are fatal errors again. As a consequence, some templates are not instantiated and lead to confusing errors. Revert to the old behavior: With CXTranslationUnit_KeepGoing fatal errors are mapped to errors. Patch by Nikolai Kosjar. Differential Revision: https://reviews.llvm.org/D58501 llvm-svn: 355586
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-071-11/+12
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355585
* Revert "[IR][ARM] Add function pointer alignment to datalayout"Mitch Phillips2019-03-061-12/+11
| | | | | | | | | | | | | This reverts commit 2391bfca97290181ae65796ea6da135d1b6d037b. This reverts rL355522 (https://reviews.llvm.org/D57335). Kills buildbots that use '-Werror' with the following error: /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm/lib/IR/Value.cpp:657:7: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] See buildbots http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30200/steps/check-llvm%20asan/logs/stdio for more information. llvm-svn: 355537
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-061-11/+12
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355522
* [clang][OpenMP] Revert "OMPFlushClause is synthetic, no such clause exists"Roman Lebedev2019-03-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts rL352390 / D57280. As discussed in https://reviews.llvm.org/D57112#inline-506781, 'flush' clause does not exist in the OpenMP spec, it can not be specified, and `OMPFlushClause` class is just a helper class. Now, here's the caveat. I have read @ABataev's > Well, I think it would be good to filter out OMPC_flush somehow > because there is no such clause actually, it is a pseudo clause > for better handling of the flush directive. as if that clause is pseudo clause that only exists for the sole purpose of simplifying the parser. As in, it never reaches AST. I did not however try to verify that. Too bad, i was wrong. It absolutely *does* reach AST. Therefore my understanding/justification for the change was flawed, which makes the patch a regression which **must** be reverted. @gribozavr has brought that up again in https://reviews.llvm.org/D57112#inline-521238 > > ... > Sorry to be late for this discussion, but I don't think this conclusion > follows. ASTMatchers are supposed to match the AST as it is. > Even if OMPC_flush is synthetic, it exists in the AST, and users might > want to match it. I think users would find anything else (trying to filter > out AST nodes that are not in the source code) to be surprising. For example, > there's a matcher materializeTemporaryExpr even though this AST node is a > Clang invention and is not a part of the C++ spec. > > Matching only constructs that appear in the source code is not feasible with > ASTMatchers, because they are based on Clang's AST that exposes tons of semantic > information, and its design is dictated by the structure of the semantic information. > See "RFC: Tree-based refactorings with Clang" in cfe-dev for a library that will > focus on representing source code as faithfully as possible. > > Not to even mention that this code is in ASTTypeTraits, a general library for > handling AST nodes, not specifically for AST Matchers... Reviewers: gribozavr, ABataev, rjmccall, aaron.ballman Reviewed By: gribozavr, ABataev Subscribers: dylanmckay, guansong, arphaman, jdoerfert, cfe-commits, gribozavr, ABataev Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D58979 llvm-svn: 355486
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-0/+37
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* Replace clang::FileData with llvm::vfs::StatusHarlan Haskins2019-03-052-51/+44
| | | | | | | | | | | | | | | | Summary: FileData was only ever used as a container for the values in llvm::vfs::Status, so they might as well be consolidated. The `InPCH` member was also always set to false, and unused. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58924 llvm-svn: 355368
* Tweak r355278 for compatibility with gcc 6 and earlier.James Y Knight2019-03-021-1/+1
| | | | llvm-svn: 355280
* Tweak r355278 for compatibility with gcc 6 and earlier.James Y Knight2019-03-021-2/+2
| | | | llvm-svn: 355279
* Make the new SanitizerMask code added in r355190 constexpr.James Y Knight2019-03-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Then, as a consequence, remove the complex set of workarounds for initialization order -- which are apparently not 100% reliable. The only downside is that some of the member functions are now specific to kNumElem == 2, and will need to be updated if that constant is increased in the future. Unfortunately, the current code caused an initialization-order runtime failure for me in some compilation modes. It appears that in a toolchain without init-array enabled, the order of initialization of static data members of a template can be reversed w.r.t. the order within a file. This caused e.g. SanitizerKind::CFI to be initialized to 0. I'm not quite sure if that is an allowable ordering variation, or nonconforming behavior, but in any case, making everything constexpr eliminates the possibility of such an issue. llvm-svn: 355278
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-03-012-3/+14
| | | | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". This is a recommit of r354873 but with a fix for unqualified lookup error in lldb cmake build bot. Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 llvm-svn: 355190
* Fix file headers. NFCFangrui Song2019-03-011-1/+1
| | | | llvm-svn: 355176
* [X86] AMD znver2 enablementGanesh Gopalasubramanian2019-02-261-0/+8
| | | | | | | | | | | | | | | | | This patch enables the following 1) AMD family 17h "znver2" tune flag (-march, -mcpu). 2) ISAs that are enabled for "znver2" architecture. 3) For the time being, it uses the znver1 scheduler model. 4) Tests are updated. 5) This patch is the clang counterpart to D58343 Reviewers: craig.topper Tags: #clang Differential Revision: https://reviews.llvm.org/D58344 llvm-svn: 354899
* revert r354873 as this breaks lldb builds.Pierre Gousseau2019-02-262-14/+3
| | | | llvm-svn: 354875
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-02-262-3/+14
| | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 llvm-svn: 354873
* [OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.Michael Kruse2019-02-251-2/+18
| | | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
* Enable coroutines under -std=c++2a.Richard Smith2019-02-232-2/+2
| | | | llvm-svn: 354736
* [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.Michael Kruse2019-02-221-2/+18
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
* Reland "[clang][FileManager] fillRealPathName even if we aren't opening the ↵Jan Korous2019-02-181-0/+3
| | | | | | | | | file" This reverts commit e2bb3121fd4ab5b01f9ec1d2e3e9877db9c6a54c. + fixed test for Windows llvm-svn: 354291
* [ARM] Add pre-defined macros for ROPI and RWPIOliver Stannard2019-02-181-0/+6
| | | | | | | | | This adds ACLE-defined macros to test for code being compiled in the ROPI and RWPI position-independence modes. Differential revision: https://reviews.llvm.org/D23610 llvm-svn: 354265
* [X86] Prevent clang clobber checking for asm flag constraints.Nirav Dave2019-02-171-1/+1
| | | | | | | Update getConstraintRegister as X86 Asm flag output constraints are no longer fully alphanumeric, llvm-svn: 354211
* Revert r354075 "[clang][FileManager] fillRealPathName even if we aren't ↵Reid Kleckner2019-02-151-3/+0
| | | | | | | | opening the file" The new test doesn't pass on Windows. llvm-svn: 354169
* [MSVC] Recognize `static_assert` keyword in C and C++98Reid Kleckner2019-02-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main effect is that clang now accepts the following conforming C11 code with MSVC headers: #include <assert.h> static_assert(1, "true"); This is a non-conforming extension (the keyword is outside the implementer's namespace), so it is placed under -fms-compatibility instead of -fms-extensions like most MSVC-specific keyword extensions. Normally, in C11, the compiler is supposed to provide the _Static_assert keyword, and assert.h should define static_assert to _Static_assert. However, that is not what MSVC does, and MSVC doesn't even provide _Static_assert. This also has the less important side effect of enabling static_assert in C++98 mode with -fms-compatibility. It's exceptionally difficult to use modern MSVC headers without C++14 even, so this is relatively unimportant. Fixes PR26672 Patch by Andrey Bokhanko! Reviewers: rsmith, thakis Subscribers: cfe-commits, STL_MSFT Differential Revision: https://reviews.llvm.org/D17444 llvm-svn: 354162
* [clang][FileManager] fillRealPathName even if we aren't opening the fileJan Korous2019-02-141-0/+3
| | | | | | | | | | | | | The pathname wasn't previously filled when the getFile() method was called with openFile = false. We are caching FileEntry-s in ParsedAST::Includes in clangd and this caused the problem. This fixes an internal test failure in clangd - ClangdTests.GoToInclude.All rdar://47536127 Differential Revision: https://reviews.llvm.org/D58213 llvm-svn: 354075
* [X86] Add clang support for X86 flag output parameters.Nirav Dave2019-02-141-0/+52
| | | | | | | | | | | | | | Summary: Add frontend support and expected flags for X86 inline assembly flag parameters. Reviewers: craig.topper, rnk, echristo Subscribers: eraman, nickdesaulniers, void, llvm-commits Differential Revision: https://reviews.llvm.org/D57394 llvm-svn: 354053
* [PowerPC] Stop defining _ARCH_PWR6X on POWER7 and upHubert Tong2019-02-131-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The predefined macro `_ARCH_PWR6X` is associated with GCC's `-mcpu=power6x` option, which enables generation of P6 "raw mode" instructions such as `mftgpr`. Later POWER processors build upon the "architected mode", not the raw one. `_ARCH_PWR6X` should not be defined for these later processors. Fixes PR#40236. Reviewers: echristo, hfinkel, kbarton, nemanjai, wschmidt Reviewed By: hfinkel Subscribers: jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58128 llvm-svn: 353975
* [Headers][mips] Add `__attribute__((__mode__(__unwind_word__)))` to the ↵Simon Atanasyan2019-02-132-0/+10
| | | | | | | | | | | | | | | | | | _Unwind_Word / _Unwind_SWord definitions The rationale of this change is to fix _Unwind_Word / _Unwind_SWord definitions for MIPS N32 ABI. This ABI uses 32-bit pointers, but _Unwind_Word and _Unwind_SWord types are eight bytes long. # The __attribute__((__mode__(__unwind_word__))) is added to the type definitions. It makes them equal to the corresponding definitions used by GCC and allows to override types using `getUnwindWordWidth` function. # The `getUnwindWordWidth` virtual function override in the `MipsTargetInfo` class and provides correct type size values. Differential revision: https://reviews.llvm.org/D58165 llvm-svn: 353965
* Add a new attribute, fortify_stdlibErik Pilkington2019-02-111-0/+25
| | | | | | | | | | | | | | | | | | | | | | This attribute applies to declarations of C stdlib functions (sprintf, memcpy...) that have known fortified variants (__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit calls to the fortified variant functions instead of calls to the defaults. In GCC, this is done by adding gnu_inline-style wrapper functions, but that doesn't work for us for variadic functions because we don't support __builtin_va_arg_pack (and have no intention to). This attribute takes two arguments, the first is 'type' argument passed through to __builtin_object_size, and the second is a flag argument that gets passed through to the variadic checking variants. rdar://47905754 Differential revision: https://reviews.llvm.org/D57918 llvm-svn: 353765
* long double is double on OpenBSD/NetBSD/PPC.Brad Smith2019-02-111-1/+7
| | | | | | Patch by George Koehler. llvm-svn: 353656
* Use llvm::is_contained. NFCFangrui Song2019-02-101-1/+1
| | | | llvm-svn: 353635
* [AMDGPU] Split dot-insts featureStanislav Mekhanoshin2019-02-091-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D57972 llvm-svn: 353588
* bpf: teach BPF driver about the new CPU "v3"Jiong Wang2019-02-071-1/+1
| | | | | | | | | This patch simply teach BPF driver about the new CPU "v3" introduced in LLVM backend. Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> llvm-svn: 353479
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-02-062-39/+31
| | | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang and lldb. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM, Clang and lldb, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 353268
* [WebAssembly] Add atomics target optionHeejin Ahn2019-02-062-0/+15
| | | | | | | | | | | | Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57798 llvm-svn: 353260
* Basic CUDA-10 support.Artem Belevich2019-02-051-1/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D57771 llvm-svn: 353232
* [DEBUG_INFO][NVPTX] Generate correct data about variable address class.Alexey Bataev2019-02-051-0/+24
| | | | | | | | | | | | | | | | | | | | | Summary: Added ability to generate correct debug info data about the variable address class. Currently, for all the locals and globals the default values are used, ADDR_local_space(6) for locals and ADDR_global_space(5) for globals. The values are taken from the table in https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf. We need to emit correct data for address classes of, at least, shared and constant globals. Currently, all these variables are treated by the cuda-gdb debugger as the variables in the global address space and, thus, it require manual data type casting. Reviewers: echristo, probinson Subscribers: jholewinski, aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D57162 llvm-svn: 353204
* [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.Michael Kruse2019-02-011-0/+11
| | | | | | | | | | | | | | | | | This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
* Do not copy long double and 128-bit fp format from aux target for AMDGPUYaxun Liu2019-01-311-0/+11
| | | | | | | | | | | | | | | rC352620 caused regressions because it copied floating point format from aux target. floating point format decides whether extended long double is supported. It is x86_fp80 on x86 but IEEE double on amdgcn. Document usage of long doubel type in HIP programming guide https://github.com/ROCm-Developer-Tools/HIP/pull/890 Differential Revision: https://reviews.llvm.org/D57527 llvm-svn: 352801
* [CUDA] Propagate detected version of CUDA to cc1Artem Belevich2019-01-311-0/+46
| | | | | | | | | | | | | ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
* [WebAssembly] Add bulk memory target featureThomas Lively2019-01-312-5/+24
| | | | | | | | | | | | Summary: Also clean up some preexisting target feature code. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, jfb Differential Revision: https://reviews.llvm.org/D57495 llvm-svn: 352793
* Revert "[CMake] Unify scripts for generating VCS headers"Petr Hosek2019-01-312-28/+42
| | | | | | This reverts commits r352729 and r352731: this broke Sanitizer Windows bots llvm-svn: 352733
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-01-312-42/+28
| | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM and Clang, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 352729
* [HIP] Fix size_t for MSVC environmentYaxun Liu2019-01-303-0/+12
| | | | | | | | | | | In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
* Simplify and modernize this code a little.Richard Smith2019-01-301-55/+30
| | | | | | No functionality change intended. llvm-svn: 352593
* Fix the behavior of clang's -w flag.James Y Knight2019-01-291-6/+11
| | | | | | | | | | It is intended to disable _all_ warnings, even those upgraded to errors via `-Werror=warningname` or `#pragma clang diagnostic error' Fixes: https://llvm.org/PR38231 Differential Revision: https://reviews.llvm.org/D53199 llvm-svn: 352535
* [clang][OpenMP] OMPFlushClause is synthetic, no such clause existsRoman Lebedev2019-01-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in https://reviews.llvm.org/D57112#inline-506781, 'flush' clause does not exist in the OpenMP spec, it can not be specified, and `OMPFlushClause` class is just a helper class. Therefore `OPENMP_CLAUSE()` in `clang/Basic/OpenMPKinds.def` should not contain 'flush' "clause". I have simply removed the `OPENMP_CLAUSE(flush, OMPFlushClause)` from `clang/Basic/OpenMPKinds.def`, grepped for `OPENMP_CLAUSE` and added `OPENMP_CLAUSE(flush, OMPFlushClause)` back to the **every** place where `OPENMP_CLAUSE` is defined and `clang/Basic/OpenMPKinds.def` is then included. So as-is, this patch is a NFC. Possibly, some of these `OPENMP_CLAUSE(flush, OMPFlushClause)` should be dropped, i don't really know. Test plan: `ninja check-clang` Reviewers: ABataev Reviewed By: ABataev Subscribers: guansong, arphaman, cfe-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D57280 llvm-svn: 352390
OpenPOWER on IntegriCloud