summaryrefslogtreecommitdiffstats
path: root/clang/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP][DOC]Provide correct info about supported features, NFC.Alexey Bataev2019-10-301-23/+2
| | | | | | | Removed the explicit list of supported features from OpenMP 5.0 and used the reference to the table instead. Also, fixed info about constructs that can be executed in SPMD mode, if and num_threads clauses do not affect it anymore.
* [OPENMP][DOC]Update list of supported functions, NFC.Alexey Bataev2019-10-301-2/+2
| | | | Added support for parallel master taskloop simd construct.
* Accept __is_same_as as a GCC-compatibility synonym for the proper trait name ↵Richard Smith2019-10-291-0/+1
| | | | __is_same.
* [Remarks] Fix Sphinx formattingFrancis Visoiu Mistrih2019-10-281-0/+3
|
* [Remarks] Add bitstream to the list of supported formats in clangFrancis Visoiu Mistrih2019-10-281-0/+2
|
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-281-1/+5
| | | | | | | | | | | | | | | | | | | Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
* [clang-format] update documentationpaulhoad2019-10-241-0/+11
| | | | | | | | | | | | | | | | | Summary: - Added example code for BreakStringLiterals; Reviewers: MyDeveloperDay Reviewed By: MyDeveloperDay Patch By: mrexodia Subscribers: cfe-commits, MyDeveloperDay Tags: #clang-tools-extra, #clang-format, #clang Differential Revision: https://reviews.llvm.org/D31574
* [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. llvm-svn: 375466
* 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. llvm-svn: 375338
* [Docs] Fix header level.Michael J. Spencer2019-10-191-1/+1
| | | | llvm-svn: 375327
* 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 llvm-svn: 375326
* [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 llvm-svn: 375322
* 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 llvm-svn: 375318
* [DOCS]Update list of implemented constructs, NFC.Alexey Bataev2019-10-181-2/+2
| | | | llvm-svn: 375257
* [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 llvm-svn: 375111
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-151-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* [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 llvm-svn: 374756
* Release notes: Add the option WarnForDeadNestedAssignmentsSylvestre Ledru2019-10-111-0/+3
| | | | | | https://reviews.llvm.org/D66733 llvm-svn: 374593
* 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 llvm-svn: 374449
* [OPENMP]Update doc for supported constructs, NFC.Alexey Bataev2019-10-101-1/+1
| | | | llvm-svn: 374438
* [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 llvm-svn: 374293
* [NFC] Reverting changes from test commit.Mitchell Balan2019-10-091-2/+0
| | | | | | llvm commit access test succeeded. llvm-svn: 374175
* [NFC] Test commit.Mitchell Balan2019-10-091-0/+2
| | | | | | Testing llvm commit access only. llvm-svn: 374174
* [ASTImporter][NFC] Update ASTImporter internals docsGabor Marton2019-10-071-11/+2
| | | | llvm-svn: 373895
* [ASTImporter][NFC] Fix typo in user docsGabor Marton2019-10-071-1/+1
| | | | llvm-svn: 373894
* [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 llvm-svn: 373844
* Try to fix sphinx indentation errorSimon Pilgrim2019-10-051-3/+5
| | | | llvm-svn: 373831
* [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 llvm-svn: 373821
* [Format] Fix docs after r373439Sam McCall2019-10-041-1/+2
| | | | llvm-svn: 373724
* [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 llvm-svn: 373647
* [ClangFormat] relnotes for r373439Sam McCall2019-10-021-1/+9
| | | | llvm-svn: 373441
* [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 llvm-svn: 373439
* 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 llvm-svn: 373308
* [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 llvm-svn: 373078
* [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 llvm-svn: 372919
* Add a release note for r372844Hans Wennborg2019-09-251-1/+12
| | | | llvm-svn: 372846
* [static analyzer] Remove --analyze-autoJan Korous2019-09-241-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D67934 llvm-svn: 372680
* 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 llvm-svn: 372621
* [docs] Fix some typos in InternalsManualSven van Haastregt2019-09-231-3/+3
| | | | llvm-svn: 372614
* [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 llvm-svn: 372516
* 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 llvm-svn: 372497
* 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 llvm-svn: 372453
* 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 llvm-svn: 372448
* [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 llvm-svn: 372387
* [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 llvm-svn: 372294
* 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 llvm-svn: 372229
* Revert "Create UsersManual section entitled 'Controlling Floating Point"Erich Keane2019-09-171-159/+30
| | | | | | This reverts commit a08d5a4b0ebd44dc64f41049ed4e97a3c6d31498. llvm-svn: 372185
* 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 llvm-svn: 372180
* [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 llvm-svn: 371839
* [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 llvm-svn: 371834
OpenPOWER on IntegriCloud