summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-211-0/+10
| | | | | | | | includes search paths and diagnostics. This is a recommit of r375322 and r375327 with a fix for the Windows test breakage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375466 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Implicit Modules] Add -cc1 option -fmodules-strict-context-hash ↵Michael J. Spencer2019-10-191-10/+0
| | | | | | | | which includes search paths and diagnostics." and "[Docs] Fix header level." The test doesn't work on Windows. I'll fix it and recommit later. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375338 91177308-0d34-0410-b5e6-96231b3b80d8
* [Docs] Fix header level.Michael J. Spencer2019-10-191-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375327 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375326 91177308-0d34-0410-b5e6-96231b3b80d8
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-191-0/+10
| | | | | | | | includes search paths and diagnostics. Differential Revision: https://reviews.llvm.org/D68528 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375322 91177308-0d34-0410-b5e6-96231b3b80d8
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-191-0/+5
| | | | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375318 91177308-0d34-0410-b5e6-96231b3b80d8
* [DOCS]Update list of implemented constructs, NFC.Alexey Bataev2019-10-181-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375257 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenCL] Add doc to describe OpenCL supportSven van Haastregt2019-10-172-0/+48
| | | | | | | | | | | The idea of this page is to document work in progress functionality and also describe the plan of future development work. Patch by Anastasia Stulova. Differential Revision: https://reviews.llvm.org/D69072 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375111 91177308-0d34-0410-b5e6-96231b3b80d8
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-151-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374934 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] loop pragmas: options implying transformationsSjoerd Meijer2019-10-141-0/+8
| | | | | | | | | | | Following our discussion on the cfe dev list: http://lists.llvm.org/pipermail/cfe-dev/2019-August/063054.html, I have added a paragraph that is explicit about loop pragmas, and transformation options implying the corresponding transformation. Differential Revision: https://reviews.llvm.org/D66199 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374756 91177308-0d34-0410-b5e6-96231b3b80d8
* Release notes: Add the option WarnForDeadNestedAssignmentsSylvestre Ledru2019-10-111-0/+3
| | | | | | | https://reviews.llvm.org/D66733 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374593 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-102-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374449 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Update doc for supported constructs, NFC.Alexey Bataev2019-10-101-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374438 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-102-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374293 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] Reverting changes from test commit.Mitchell Balan2019-10-091-2/+0
| | | | | | | llvm commit access test succeeded. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374175 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] Test commit.Mitchell Balan2019-10-091-0/+2
| | | | | | Testing llvm commit access only. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374174 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter][NFC] Update ASTImporter internals docsGabor Marton2019-10-071-11/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373895 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter][NFC] Fix typo in user docsGabor Marton2019-10-071-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373894 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format][docs] Fix the Google C++ and Chromium style guide URLsPaul Hoad2019-10-061-1/+1
| | | | | | | | | | | | | | | | | | Summary: The Google C++ and Chromium style guides are broken in the clang-format docs. This patch updates them. Reviewers: djasper, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang Patch by: m4tx Differential Revision: https://reviews.llvm.org/D61256 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373844 91177308-0d34-0410-b5e6-96231b3b80d8
* Try to fix sphinx indentation errorSimon Pilgrim2019-10-051-3/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373831 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] SpacesInSquareBrackets should affect lambdas with parameters tooPaul Hoad2019-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters. Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice. See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944. Reviewers: MyDeveloperDay, reuk, owenpan Reviewed By: MyDeveloperDay Subscribers: cfe-commits Patch by: mitchell-stellar Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D68473 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373821 91177308-0d34-0410-b5e6-96231b3b80d8
* [Format] Fix docs after r373439Sam McCall2019-10-041-1/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373724 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add ability to wrap braces after multi-line control statementsPaul Hoad2019-10-031-15/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values: * "Never": This is the default, and does not do any brace wrapping after control statements. * "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified). * "Always": This always wraps braces after control statements. The first and last options are backwards-compatible with "false" and "true", respectively. The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example: ``` if ( foo && bar ) { baz(); } ``` vs. ``` if ( foo && bar ) { baz(); } ``` Short control statements (1 line) do not wrap the brace to the next line, e.g. ``` if (foo) { bar(); } else { baz(); } ``` Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek Reviewed By: MyDeveloperDay Subscribers: MyDeveloperDay, cfe-commits Patch By: mitchell-stellar Tags: #clang-format, #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D68296 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373647 91177308-0d34-0410-b5e6-96231b3b80d8
* [ClangFormat] relnotes for r373439Sam McCall2019-10-021-1/+9
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373441 91177308-0d34-0410-b5e6-96231b3b80d8
* [ClangFormat] Future-proof Standard option, allow floating or pinning to ↵Sam McCall2019-10-021-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arbitrary lang version Summary: The historical context: - clang-format was written when C++11 was current, and the main language-version concern was >> vs > > template-closers. An option was added to allow selection of the 03/11 behavior, or auto-detection. - there was no option to choose simply "latest standard" so anyone who didn't ever want 03 behavior or auto-detection specified Cpp11. - In r185149 this option started to affect lexer mode. - no options were added to cover c++14, as parsing/formatting didn't change that much. The usage of Cpp11 to mean "latest" became codified e.g. in r206263 - c++17 added some new constructs. These were mostly backwards-compatible and so not used in old programs, so having no way to turn them off was OK. - c++20 added some new constructs and keywords (e.g. co_*) that changed the meaning of existing programs, and people started to complain that the c++20 parsing couldn't be turned off. New plan: - Default ('Auto') behavior remains unchanged: parse as latest, format template-closers based on input. - Add new 'Latest' option that more clearly expresses the intent "use modern features" that many projects have chosen for their .clang-format files. - Allow pinning to *any* language version, using the same name as clang -std: c++03, c++11, c++14 etc. These set precise lexer options, and any clang-format code depending on these can use a >= check. - For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`. This matches the historical documented semantics of this option. This spelling (and `Cpp03`) are deprecated. Reviewers: klimek, modocache Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67541 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373439 91177308-0d34-0410-b5e6-96231b3b80d8
* Decrease the verbosity of the -ftime-trace optionSylvestre Ledru2019-10-011-1/+2
| | | | | | | | | | | | | | | | | | | | | And move the relevant information in the doc. Summary: Currently, building a large software like Firefox shows 'Use chrome://tracing or Speedscope App (https://www.speedscope.app) for flamegraph visualization' for each file. Reviewers: anton-afanasyev Reviewed By: anton-afanasyev Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68260 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373308 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang] [AST] Treat "inline gnu_inline" the same way as "extern inline ↵Martin Storsjo2019-09-271-1/+4
| | | | | | | | | | | | | | | | | gnu_inline" in C++ mode This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl. GCC documents the gnu_inline attribute with "In C++, this attribute does not depend on extern in any way, but it still requires the inline keyword to enable its special behavior." The previous behaviour of gnu_inline in C++, without the extern keyword, can be traced back to the original commit that added support for gnu_inline, SVN r69045. Differential Revision: https://reviews.llvm.org/D67414 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373078 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Modified SortIncludes and IncludeCategories to priority for ↵Paul Hoad2019-09-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | sorting #includes within the Group Category. Summary: This new Style rule is made as a part of adding support for NetBSD KNF in clang-format. NetBSD have it's own priority of includes which should be followed while formatting NetBSD code. This style sorts the Cpp Includes according to the priorities of NetBSD, as mentioned in the [Style Guide](http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD&content-type=text/x-cvsweb-markup) The working of this Style rule shown below: **Configuration:** This revision introduces a new field under IncludeCategories named `SortPriority` which defines the priority of ordering the `#includes` and the `Priority` will define the categories for grouping the `#include blocks`. Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski Patch By: Manikishan Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D64695 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372919 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a release note for r372844Hans Wennborg2019-09-251-1/+12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372846 91177308-0d34-0410-b5e6-96231b3b80d8
* [static analyzer] Remove --analyze-autoJan Korous2019-09-241-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D67934 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372680 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix __is_signed builtinZoe Carver2019-09-231-4/+1
| | | | | | | | | | | | | | Summary: This patch fixes the __is_signed builtin type trait to work with floating point types and enums. Now, the builtin will return true if it is passed a floating point type and false for an enum type. Reviewers: EricWF, rsmith, erichkeane, craig.topper, efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67897 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372621 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Fix some typos in InternalsManualSven van Haastregt2019-09-231-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372614 91177308-0d34-0410-b5e6-96231b3b80d8
* [CLANG][BPF] permit any argument type for __builtin_preserve_access_index()Yonghong Song2019-09-221-3/+4
| | | | | | | | | | | | | | | | | | | | Commit c15aa241f821 ("[CLANG][BPF] change __builtin_preserve_access_index() signature") changed the builtin function signature to PointerT __builtin_preserve_access_index(PointerT ptr) with a pointer type as the argument/return type, where argument and return types must be the same. There is really no reason for this constraint. The builtin just presented a code region so that IR builtins __builtin_{array, struct, union}_preserve_access_index can be applied. This patch removed the pointer type restriction to permit any argument type as long as it is permitted by the compiler. Differential Revision: https://reviews.llvm.org/D67883 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372516 91177308-0d34-0410-b5e6-96231b3b80d8
* Clang-format: Add Whitesmiths indentation stylePaul Hoad2019-09-221-0/+28
| | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for the Whitesmiths indentation style to clang-format. It’s an update to a patch submitted in 2015 (D6833), but reworks it to use the newer API. There are still some issues with this patch, primarily around `switch` and `case` support. The added unit test won’t currently pass because of the remaining issues. Reviewers: mboehme, MyDeveloperDay, djasper Reviewed By: MyDeveloperDay Subscribers: krasimir, MyDeveloperDay, echristo, cfe-commits Patch By: @timwoj (Tim Wojtulewicz) Tags: #clang Differential Revision: https://reviews.llvm.org/D67627 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372497 91177308-0d34-0410-b5e6-96231b3b80d8
* Merge and improve code that detects same value in comparisons.Richard Trieu2019-09-211-0/+3
| | | | | | | | | | | | | -Wtautological-overlap-compare and self-comparison from -Wtautological-compare relay on detecting the same operand in different locations. Previously, each warning had it's own operand checker. Now, both are merged together into one function that each can call. The function also now looks through member access and array accesses. Differential Revision: https://reviews.llvm.org/D66045 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372453 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve -Wtautological-overlap-compareRichard Trieu2019-09-211-1/+2
| | | | | | | | | | Allow this warning to detect a larger number of constant values, including negative numbers, and handle non-int types better. Differential Revision: https://reviews.llvm.org/D66044 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372448 91177308-0d34-0410-b5e6-96231b3b80d8
* [SystemZ] Add SystemZ as supporting target in help text for -mfentry.Jonas Paulsson2019-09-201-1/+1
| | | | | | | | => "Insert calls to fentry at function entry (x86/SystemZ only)" Review: Ulrich Weigand git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372387 91177308-0d34-0410-b5e6-96231b3b80d8
* [CLANG][BPF] change __builtin_preserve_access_index() signatureYonghong Song2019-09-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The clang intrinsic __builtin_preserve_access_index() currently has signature: const void * __builtin_preserve_access_index(const void * ptr) This may cause compiler warning when: - parameter type is "volatile void *" or "const volatile void *", or - the assign-to type of the intrinsic does not have "const" qualifier. Further, this signature does not allow dereference of the builtin result pointer as it is a "const void *" type, which adds extra step for the user to do type casting. Let us change the signature to: PointerT __builtin_preserve_access_index(PointerT ptr) such that the result and argument types are the same. With this, directly dereferencing the builtin return value becomes possible. Differential Revision: https://reviews.llvm.org/D67734 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372294 91177308-0d34-0410-b5e6-96231b3b80d8
* Recommit -r372180Erich Keane2019-09-181-30/+179
| | | | | | | | | | | | | | | | | | Commit message below, original caused the sphinx build bot to fail, this one should fix it. Create UsersManual section entitled 'Controlling Floating Point Behavior' Create a new section for documenting the floating point options. Move all the floating point options into this section, and add new entries for the floating point options that exist but weren't previously described in the UsersManual. Patch By: mibintc Differential Revision: https://reviews.llvm.org/D67517 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372229 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Create UsersManual section entitled 'Controlling Floating Point"Erich Keane2019-09-171-159/+30
| | | | | | This reverts commit a08d5a4b0ebd44dc64f41049ed4e97a3c6d31498. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372185 91177308-0d34-0410-b5e6-96231b3b80d8
* Create UsersManual section entitled 'Controlling Floating PointErich Keane2019-09-171-30/+159
| | | | | | | | | | | | | | Behavior' Create a new section for documenting the floating point options. Move all the floating point options into this section, and add new entries for the floating point options that exist but weren't previously described in the UsersManual. Patch By: mibintc Differential Revision: https://reviews.llvm.org/D67517 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372180 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter] Add development internals docsGabor Marton2019-09-131-0/+489
| | | | | | | | | | | | Reviewers: a_sidorin, shafik, teemperor, gamesh411, balazske, dkrupp, a.sidorin Subscribers: rnkovacs, Szelethus, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66336 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371839 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-132-0/+195
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371834 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add new style option IndentGotoLabelsPaul Hoad2019-09-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left. This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk. ``` true: false: int f() { vs. int f() { if (foo()) { if (foo()) { label1: label1: bar(); bar(); } } label2: label2: return 1; return 1; } } ``` Reviewers: klimek, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang, #clang-tools-extra Patch by: tetsuo-cpp Differential Revision: https://reviews.llvm.org/D67037 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371719 91177308-0d34-0410-b5e6-96231b3b80d8
* [X86] Enable -mprefer-vector-width=256 by default for Skylake-avx512 and ↵Craig Topper2019-09-111-2/+6
| | | | | | | | | | | | | | | | later Intel CPUs. AVX512 instructions can cause a frequency drop on these CPUs. This can negate the performance gains from using wider vectors. Enabling prefer-vector-width=256 will prevent generation of zmm registers unless explicit 512 bit operations are used in the original source code. I believe gcc and icc both do something similar to this by default. Differential Revision: https://reviews.llvm.org/D67259 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371694 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Updated status page, NFC.Alexey Bataev2019-09-111-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371627 91177308-0d34-0410-b5e6-96231b3b80d8
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-1/+4
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371169 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenMP][Docs] Provide implementation status detailsJohannes Doerfert2019-09-041-4/+132
| | | | | | | | | | | | | | | This adds a more fine-grained list of OpenMP features with their implementation status and associated reviews/commits. Reviewers: kkwli0, ABataev, RaviNarayanaswamy, gtbercea, Hahnfeld Subscribers: bollu, guansong, jfb, hfinkel, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64375 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370930 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev2019-09-042-195/+0
| | | | | | | | | Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency graphs. (clangInterp depends on clangAST which depends on clangInterp) This reverts r370839, which is an yet another recommit of D64146. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370874 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-042-0/+195
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370839 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status