summaryrefslogtreecommitdiffstats
path: root/clang/test
Commit message (Collapse)AuthorAgeFilesLines
* [OpenMP][test] Fix test on MIPS-based buildbotsMiloš Stojanović2019-11-281-1/+1
| | | | | | On MIPS `zeroext` or `signext` can appear in the output. Differential Revision: https://reviews.llvm.org/D70820
* Properly disambiguate between array declarators and array subscript expressions.Richard Smith2019-11-271-0/+22
|
* [CodeGen] Fix clang crash on aggregate initialization of array of labelsJohannes Altmanninger2019-11-281-0/+6
| | | | | | | | | | | | | | | Summary: Fix PR43700 The ConstantEmitter in AggExprEmitter::EmitArrayInit was initialized with the CodeGenFunction set to null, which caused the crash. Also simplify another call, and make the CGF member a const pointer since it is public but only assigned in the constructor. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70302
* Try to reenable -Wdeprecated-copy under -WextraDávid Bolvanský2019-11-271-0/+1
|
* [ConstExprPreter] Removed the flag forcing the use of the interpreterNandor Licker2019-11-271-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Removed the ```-fforce-experimental-new-constant-interpreter flag```, leaving only the ```-fexperimental-new-constant-interpreter``` one. The interpreter now always emits an error on an unsupported feature. Allowing the interpreter to bail out would require a mapping from APValue to interpreter memory, which will not be necessary in the final version. It is more sensible to always emit an error if the interpreter fails. Reviewers: jfb, Bigcheese, rsmith, dexonsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70071
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-2710-0/+1557
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054)(take 2) Summary: Implicit Conversion Sanitizer is *almost* feature complete. There aren't *that* much unsanitized things left, two major ones are increment/decrement (this patch) and bit fields. As it was discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]], unlike `CompoundAssignOperator` (which is promoted internally), or `BinaryOperator` (for which we always have promotion/demotion in AST) or parts of `UnaryOperator` (we have promotion/demotion but only for certain operations), for inc/dec, clang omits promotion/demotion altogether, under as-if rule. This is technically correct: https://rise4fun.com/Alive/zPgD As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`, `add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily be extended or truncated: https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334 But that has serious implications: 1. Since we no longer model implicit casts, do we pessimise their AST representation and everything that uses it? 2. There is no demotion, so lossy demotion sanitizer does not trigger :] Now, i'm not going to argue about the first problem here, but the second one **needs** to be addressed. As it was stated in the report, this is done intentionally, so changing this in all modes would be considered a penalization/regression. Which means, the sanitization-less codegen must not be altered. It was also suggested to not change the sanitized codegen to the one with demotion, but i quite strongly believe that will not be the wise choice here: 1. One will need to re-engineer the check that the inc/dec was lossy in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins 2. We will still need to compute the result we would lossily demote. (i.e. the result of wide `add`ition/`sub`traction) 3. I suspect it would need to be done right here, in sanitization. Which kinda defeats the point of using `@llvm.{u,s}{add,sub}.with.overflow` builtins: we'd have two `add`s with basically the same arguments, one of which is used for check+error-less codepath and other one for the error reporting. That seems worse than a single wide op+check. 4. OR, we would need to do that in the compiler-rt handler. Which means we'll need a whole new handler. But then what about the `CompoundAssignOperator`, it would also be applicable for it. So this also doesn't really seem like the right path to me. 5. At least X86 (but likely others) pessimizes all sub-`i32` operations (due to partial register stalls), so even if we avoid promotion+demotion, the computations will //likely// be performed in `i32` anyways. So i'm not really seeing much benefit of not doing the straight-forward thing. While looking into this, i have noticed a few more LLVM middle-end missed canonicalizations, and filed [[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]]. Those are not specific to inc/dec, we also have them for `CompoundAssignOperator`, and it can happen for normal arithmetics, too. But if we take some other path in the patch, it will not be applicable here, and we will have most likely played ourselves. TLDR: front-end should emit canonical, easy-to-optimize yet un-optimized code. It is middle-end's job to make it optimal. I'm really hoping reviewers agree with my personal assessment of the path this patch should take.. This originally landed in 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9 but got immediately reverted in cbfa237892e55b7129a1178c9b03f26683d643af because the assertion was faulty. That fault ended up being caused by the enum - while there will be promotion, both types are unsigned, with same width. So we still don't need to sanitize non-signed cases. So far. Maybe the assert will tell us this isn't so. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. Refs. https://github.com/google/sanitizers/issues/940 Reviewers: rjmccall, erichkeane, rsmith, vsk Reviewed By: erichkeane Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D70539
* [LifetimeAnalysis] Fix PR44150Gabor Horvath2019-11-271-0/+5
| | | | | | | | References need somewhat special treatment. While copying a gsl::Pointer will propagate the points-to set, creating an object from a reference often behaves more like a dereference operation. Differential Revision: https://reviews.llvm.org/D70755
* [ARM][MVE][Intrinsics] Add MVE VAND/VORR/VORN/VEOR/VBIC intrinsics. Add unit ↵Mark Murray2019-11-275-0/+364
| | | | | | | | | | | | | | tests. Summary: Add MVE VAND/VORR/VORN/VEOR/VBIC intrinsics. Add unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70547
* [ARM][MVE][Intrinsics] Add MVE VMUL intrinsics. Remove annoying "t1" from ↵Mark Murray2019-11-271-0/+125
| | | | | | | | | | | | | | VMUL* instructions. Add unit tests. Summary: Add MVE VMUL intrinsics. Remove annoying "t1" from VMUL* instructions. Add unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70546
* [ARM][MVE][Intrinsics] Add MVE VABD intrinsics. Add unit tests.Mark Murray2019-11-271-0/+95
| | | | | | | | | | | | Summary: Add MVE VABD intrinsics. Add unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70545
* [OPENMP50]Add if clause in parallel for simd directive.Alexey Bataev2019-11-271-43/+124
| | | | | According to OpenMP 5.0, if clause can be used in parallel for simd directive. If condition in the if clause if false, the non-vectorized version of the loop must be executed.
* Revert "[clang][CodeGen] Implicit Conversion Sanitizer: handle ↵Roman Lebedev2019-11-279-1545/+0
| | | | | | | | | | increment/decrement (PR44054)" The asssertion that was added does not hold, breaks on test-suite/MultiSource/Applications/SPASS/analyze.c Will reduce the testcase and revisit. This reverts commit 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9, 870f3542d3e0d06d208442bdca6482866b59171b.
* [ARM] Replace arm_neon_vqadds with sadd_satDavid Green2019-11-272-60/+60
| | | | | | | | | | This replaces the A32 NEON vqadds, vqaddu, vqsubs and vqsubu intrinsics with the target independent sadd_sat, uadd_sat, ssub_sat and usub_sat. This helps generate vqadds from standard IR nodes, which might be produced from the vectoriser. The old variants are removed in the process. Differential Revision: https://reviews.llvm.org/D69350
* [CodeGen][UBSan] Relax newly-added verbose sanitization tests for inc/decRoman Lebedev2019-11-272-32/+32
| | | | | In particular, don't hardcode the signature of the handler: it takes src filepath so the length of buffers will not match,
* [OpenCL] Move addr space deduction to Sema.Anastasia Stulova2019-11-277-15/+67
| | | | | | | | | | | | | | | | In order to simplify implementation we are moving add space deduction into Sema while constructing variable declaration and on template instantiation. Pointee are deduced to generic addr space during creation of types. This commit also - fixed addr space dedution for auto type; - factors out in a separate helper function OpenCL specific logic from type diagnostics in var decl. Tags: #clang Differential Revision: https://reviews.llvm.org/D65744
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-279-0/+1545
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054) Summary: Implicit Conversion Sanitizer is *almost* feature complete. There aren't *that* much unsanitized things left, two major ones are increment/decrement (this patch) and bit fields. As it was discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]], unlike `CompoundAssignOperator` (which is promoted internally), or `BinaryOperator` (for which we always have promotion/demotion in AST) or parts of `UnaryOperator` (we have promotion/demotion but only for certain operations), for inc/dec, clang omits promotion/demotion altogether, under as-if rule. This is technically correct: https://rise4fun.com/Alive/zPgD As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`, `add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily be extended or truncated: https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334 But that has serious implications: 1. Since we no longer model implicit casts, do we pessimise their AST representation and everything that uses it? 2. There is no demotion, so lossy demotion sanitizer does not trigger :] Now, i'm not going to argue about the first problem here, but the second one **needs** to be addressed. As it was stated in the report, this is done intentionally, so changing this in all modes would be considered a penalization/regression. Which means, the sanitization-less codegen must not be altered. It was also suggested to not change the sanitized codegen to the one with demotion, but i quite strongly believe that will not be the wise choice here: 1. One will need to re-engineer the check that the inc/dec was lossy in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins 2. We will still need to compute the result we would lossily demote. (i.e. the result of wide `add`ition/`sub`traction) 3. I suspect it would need to be done right here, in sanitization. Which kinda defeats the point of using `@llvm.{u,s}{add,sub}.with.overflow` builtins: we'd have two `add`s with basically the same arguments, one of which is used for check+error-less codepath and other one for the error reporting. That seems worse than a single wide op+check. 4. OR, we would need to do that in the compiler-rt handler. Which means we'll need a whole new handler. But then what about the `CompoundAssignOperator`, it would also be applicable for it. So this also doesn't really seem like the right path to me. 5. At least X86 (but likely others) pessimizes all sub-`i32` operations (due to partial register stalls), so even if we avoid promotion+demotion, the computations will //likely// be performed in `i32` anyways. So i'm not really seeing much benefit of not doing the straight-forward thing. While looking into this, i have noticed a few more LLVM middle-end missed canonicalizations, and filed [[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]]. Those are not specific to inc/dec, we also have them for `CompoundAssignOperator`, and it can happen for normal arithmetics, too. But if we take some other path in the patch, it will not be applicable here, and we will have most likely played ourselves. TLDR: front-end should emit canonical, easy-to-optimize yet un-optimized code. It is middle-end's job to make it optimal. I'm really hoping reviewers agree with my personal assessment of the path this patch should take.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. Reviewers: rjmccall, erichkeane, rsmith, vsk Reviewed By: erichkeane Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D70539
* Revert "Revert "As a follow-up to my initial mail to llvm-dev here's a first ↵Eric Christopher2019-11-2616-85/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | pass at the O1 described there."" This reapplies: 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4 Original commit message: As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there. This change doesn't include any change to move from selection dag to fast isel and that will come with other numbers that should help inform that decision. There also haven't been any real debuggability studies with this pipeline yet, this is just the initial start done so that people could see it and we could start tweaking after. Test updates: Outside of the newpm tests most of the updates are coming from either optimization passes not run anymore (and without a compelling argument at the moment) that were largely used for canonicalization in clang. Original post: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410 This reverts commit c9ddb02659e3ece7a0d9d6b4dac7ceea4ae46e6d.
* XFAIL a test on WindowsFangrui Song2019-11-261-0/+1
| | | | | | | | | | | | http://45.33.8.238/win/3052/step_6.txt C:\src\llvm-project\clang\test\Preprocessor\file_test.c:9:11: error: CHECK: expected string not found in input // CHECK: filename: "/UNLIKELY_PATH/empty{{/|\\\\}}file_test.c" ^ <stdin>:1:1: note: scanning from here ^ <stdin>:1:28: note: possible intended match here ^
* Workaround for EvalInfo ctor for MSVC 2017Yaxun (Sam) Liu2019-11-261-0/+9
| | | | | | | | | | | | Current EvalInfo ctor causes EnableNewConstInterp to be true even though it is supposed to be false on MSVC 2017. This is because a virtual function getLangOpts() is called in member initializer lists, whereas on MSVC member ctors are called before function virtual function pointers are initialized. This patch fixes that. Differential Revision: https://reviews.llvm.org/D70729
* [Preprocessor] Fix backslash tests on Windows after D49466Fangrui Song2019-11-261-6/+6
| | | | See http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/29442/steps/test-check-all/logs/stdio
* Fix tests on Windows after D49466Fangrui Song2019-11-261-6/+6
| | | | | | It is tricky to use replace_path_prefix correctly on Windows which uses backslashes as native path separators. Switch back to the old approach (startswith is not ideal) to appease build bots for now.
* Initial implementation of -fmacro-prefix-map and -ffile-prefix-mapDan McGregor2019-11-265-9/+55
| | | | | | | | | GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro. -ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map Reviewed By: rnk, Lekensteyn, maskray Differential Revision: https://reviews.llvm.org/D49466
* [OPENMP]Fix PR44133: crash on lambda reductions in templates.Alexey Bataev2019-11-261-0/+43
| | | | | | Need to perform the instantiation of the combiner/initializer even if the resulting type is not dependent, if the construct is defined in templates in some cases.
* Partially reland "[Diagnostics] Put "deprecated copy" warnings into ↵Dávid Bolvanský2019-11-261-0/+22
| | | | | | -Wdeprecated-copy"" But do not enable it under -Wextra until libcxx issue is solved.
* [OpenCL] Add work-group and miscellaneous vector builtin functionsSven van Haastregt2019-11-261-0/+8
| | | | | | | Add the work-group and miscellaneous vector builtin functions from the OpenCL C specification. Patch by Pierre Gondois and Sven van Haastregt.
* Recommit ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.Tim Northover2019-11-262-4/+7
| | | | | | | | | | | | | | | | | | The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations that might be needed, and we were quite quickly running out of letters to use. This patch converts to a much smaller set of orthogonal modifiers that can be applied together to achieve the desired effect. When merging with downstream it is likely to cause a conflict with any local modifications to the .td files. There is a new script in utils/convert_arm_neon.py that was used to convert all .td definitions and I would suggest running it on the last downstream version of those files before this commit rather than resolving conflicts manually. The original version broke vcreate_* because it became a macro and didn't apply the normal integer promotion rules before bitcasting to a vector. This adds a temporary.
* Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at ↵Muhammad Omair Javaid2019-11-2616-82/+85
| | | | | | | | | | | | | | | | | | | | | | | the O1 described there." This reverts commit 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4. This commit introduced 9 new failures on lldb buildbot host at http://lab.llvm.org:8014/builders/lldb-aarch64-ubuntu Following tests were failing: lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq1/TestAmbiguousTailCallSeq1.py lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py lldb-api :: functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py lldb-api :: functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410
* [clang][CodeGen] Fix wrong memcpy size of no_unique_address in FieldMemcpyizerSenran Zhang2019-11-251-0/+25
| | | | | | | | | | When generating ctor, FieldMemcpyizer wrongly treated zero-sized class members as what should be copied, and generated wrong memcpy size under some special circumstances. This patch tries to fix it. Reviewed By: MaskRay, rjmccall Differential Revision: https://reviews.llvm.org/D70671
* As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 ↵Eric Christopher2019-11-2516-85/+82
| | | | | | | | | | | | | | | | | | | | | described there. This change doesn't include any change to move from selection dag to fast isel and that will come with other numbers that should help inform that decision. There also haven't been any real debuggability studies with this pipeline yet, this is just the initial start done so that people could see it and we could start tweaking after. Test updates: Outside of the newpm tests most of the updates are coming from either optimization passes not run anymore (and without a compelling argument at the moment) that were largely used for canonicalization in clang. Original post: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410
* IRGen: Call SetLLVMFunctionAttributes{,ForDefinition} on __cfi_check_fail.Peter Collingbourne2019-11-251-0/+5
| | | | | | | | | | | | | | This has the main effect of causing target-cpu and target-features to be set on __cfi_check_fail, causing the function to become ABI-compatible with other functions in the case where these attributes affect ABI (e.g. reserve-x18). Technically we only need to call SetLLVMFunctionAttributes to get the target-* attributes set, but since we're creating a definition we probably ought to call the ForDefinition function as well. Fixes PR44094. Differential Revision: https://reviews.llvm.org/D70692
* Disallow use of __has_c_attribute in C++ mode.Aaron Ballman2019-11-252-0/+14
| | | | | | | __has_cpp_attribute is not available in C mode, and __has_c_attribute should not be available in C++ mode. This also adds a test to demonstrate that we properly handle scoped attribute tokens even in C mode.
* Revert "[Diagnostic] add a warning which warns about misleading indentation"Tom Stellard2019-11-254-187/+1
| | | | | | This reverts commit 7b86188b50bf6e537fe98b326f258fbd23108b83. This commit introduced bot falures for multi-stage bots with -Werror.
* Revert "[Diagnostics] Put "deprecated copy" warnings into -Wdeprecated-copy"Tom Stellard2019-11-251-23/+0
| | | | | | This reverts commit 9353c5dd0664ea444236e527bf93566e11dc34df. This commit introduced bot falures for multi-stage bots with -Werror.
* [OPENMP]Fix PR41826: symbols visibility in device code.Alexey Bataev2019-11-255-27/+27
| | | | | | | | | | | | | | | | | | Summary: Currently, we ignore all locality attributes/info when building for the device and thus all symblos are externally visible and can be preemted at the runtime. It may lead to incorrect results. We need to follow the same logic, compiler uses for static/pie builds. But in some cases changing of dso locality may lead to problems with codegen, so instead mark external symbols as hidden instead in the device code. Reviewers: jdoerfert Subscribers: guansong, caomhin, kkwli0, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70549
* [Diagnostic] add a warning which warns about misleading indentationTyker2019-11-254-1/+187
| | | | | | | | | | | | Summary: Add a warning for misleading indentation similar to GCC's -Wmisleading-indentation Reviewers: aaron.ballman, xbolva00 Reviewed By: aaron.ballman, xbolva00 Subscribers: arphaman, Ka-Ka, thakis Differential Revision: https://reviews.llvm.org/D70638
* Revert 3f91705ca54 "ARM-NEON: make type modifiers orthogonal and allow ↵Hans Wennborg2019-11-252-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multiple modifiers." This broke the vcreate_u64 intrinsic. Example: $ cat /tmp/a.cc #include <arm_neon.h> void g() { auto v = vcreate_u64(0); } $ bin/clang -c /tmp/a.cc --target=arm-linux-androideabi16 -march=armv7-a /tmp/a.cc:4:12: error: C-style cast from scalar 'int' to vector 'uint64x1_t' (vector of 1 'uint64_t' value) of different size auto v = vcreate_u64(0); ^~~~~~~~~~~~~~ /work/llvm.monorepo/build.release/lib/clang/10.0.0/include/arm_neon.h:4144:11: note: expanded from macro 'vcreate_u64' __ret = (uint64x1_t)(__p0); \ ^~~~~~~~~~~~~~~~~~ Reverting until this can be investigated. > The modifier system used to mutate types on NEON intrinsic definitions had a > separate letter for all kinds of transformations that might be needed, and we > were quite quickly running out of letters to use. This patch converts to a much > smaller set of orthogonal modifiers that can be applied together to achieve the > desired effect. > > When merging with downstream it is likely to cause a conflict with any local > modifications to the .td files. There is a new script in > utils/convert_arm_neon.py that was used to convert all .td definitions and I > would suggest running it on the last downstream version of those files before > this commit rather than resolving conflicts manually.
* [Diagnostics] Warn for comparison with string literals expanded from macro ↵Dávid Bolvanský2019-11-242-1/+30
| | | | | | | | | | | | | | | | | | (PR44064) Summary: As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases. Clang missed a real bug in the code I am working with, GCC caught it. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70624
* [Diagnostics] Make behaviour of Clang's -Wdeprecated-copy same as in GCCDávid Bolvanský2019-11-231-0/+6
| | | | Do not warn for functions that are explicitly marked delete or default, which follows the behavior of the GCC warning.
* [analyzer] Add custom filter functions for GenericTaintCheckerBorsik Gabor2019-11-232-2/+12
| | | | | | | | | | | This patch is the last of the series of patches which allow the user to annotate their functions with taint propagation rules. I implemented the use of the configured filtering functions. These functions can remove taintedness from the symbols which are passed at the specified arguments to the filters. Differential Revision: https://reviews.llvm.org/D59516
* [Driver] Fix incorrect GNU triplet for PowerPC on SUSE LinuxAaron Puchert2019-11-236-0/+15
| | | | | | | | | | | | | | | Summary: On SUSE distributions for 32-bit PowerPC, gcc is configured as a 64-bit compiler using the GNU triplet "powerpc64-suse-linux", but invoked with "-m32" by default. Thus, the correct GNU triplet for 32-bit PowerPC SUSE distributions is "powerpc64-suse-linux" and not "powerpc-suse-linux". Reviewers: jrtc27, nemanjai, glaubitz Reviewed By: nemanjai Differential Revision: https://reviews.llvm.org/D55326
* [RISCV] Add missing REQUIRES to clang testsDavid Zarzycki2019-11-232-2/+2
| | | | Fixes: e0f22fe04a5c9eb244ff0533549743b7deb03b99
* [WebAssembly] Use wasm-opt and LTO libraries when available.Dan Gohman2019-11-221-0/+6
| | | | | | | | | | When there's a wasm-opt in the PATH, run the it to optimize LLVM's output. This fixes PR43796. And, add an "llvm-lto" directory to the sysroot library search paths, so that sysroots can provide LTO-enabled system libraries. Differential Revision: https://reviews.llvm.org/D70500
* DebugInfo: Flag Dwarf Version metadata for merging during LTODavid Blaikie2019-11-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | When the Dwarf Version metadata was initially added (r184276) there was no support for Module::Max - though the comment suggested that was the desired behavior. The original behavior was Module::Warn which would warn and then pick whichever version came first - which is pretty arbitrary/luck-based if the consumer has some need for one version or the other. Now that the functionality's been added (r303590) this change updates the implementation to match the desired goal. The general logic here is - if you compile /some/ of your program with a more recent DWARF version, you must have a consumer that can handle it, so might as well use it for /everything/. The only place where this might fall down is if you have a need to use an old tool (supporting only the older DWARF version) for some subset of your program. In which case now it'll all be the higher version. That seems pretty narrow (& the inverse could happen too - you specifically /need/ the higher DWARF version for some extra expressivity, etc, in some part of the program)
* [Driver] Make -static-libgcc imply static libunwindJosh Kunz2019-11-221-1/+9
| | | | | | | | | | | | | | | | | | In the GNU toolchain, `-static-libgcc` implies that the unwindlib will be linked statically. However, when `--unwindlib=libunwind`, this flag is ignored, and a bare `-lunwind` is added to the linker args. Unfortunately, this means that if both `libunwind.so`, and `libunwind.a` are present in the library path, `libunwind.so` will be chosen in all cases where `-static` is not set. This change makes `-static-libgcc` affect the `-l` flag produced by `--unwindlib=libunwind`. After this patch, providing `-static-libgcc --unwindlib=libunwind` will cause the driver to explicitly emit `-l:libunwind.a` to statically link libunwind. For all other cases it will emit `-l:libunwind.so` matching current behavior with a more explicit link line. https://reviews.llvm.org/D70416
* Revert "[Sema] Use the canonical type in function isVector"Akira Hatanaka2019-11-221-7/+0
| | | | | This reverts commit a6150b48cea00ab31e9335cc73770327acc4cb3a. The commit broke a few neon CodeGen tests.
* [Diagnostics] Put "deprecated copy" warnings into -Wdeprecated-copyDávid Bolvanský2019-11-221-0/+23
| | | | | | | | | | | | | | | | | Summary: GCC 9 added -Wdeprecated-copy (as part of -Wextra). This diagnostic is already implemented in Clang too, just hidden under -Wdeprecated (not on by default). This patch adds -Wdeprecated-copy and makes it compatible with GCC 9+. This diagnostic is heavily tested in deprecated.cpp, so I added simple tests just to check we warn when new flag/-Wextra is enabled. Reviewers: rsmith, dblaikie Reviewed By: dblaikie Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70342
* [Sema] Use the canonical type in function isVectorAkira Hatanaka2019-11-221-0/+7
| | | | | | | This fixes an assertion in Sema::CreateBuiltinBinOp that fails when one of the vector operand's element type is a typedef of __fp16. rdar://problem/55983556
* Fix typo to separate "-x" from warning flag.Bill Wendling2019-11-221-1/+1
|
* Don't report "main" as missing a prototype in freestanding modeBill Wendling2019-11-221-0/+6
| | | | | | | | | | | | | | | | | Summary: A user may want to use freestanding mode with the standard "main" entry point. It's not useful to warn about a missing prototype as it's not typical to have a prototype for "main". Reviewers: efriedma, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70588
* [RISCV] Use compiler-rt if no GCC installation detectedEdward Jones2019-11-224-37/+83
| | | | | | | | If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
OpenPOWER on IntegriCloud