summaryrefslogtreecommitdiffstats
path: root/clang/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* Update the docs for using LLVM toolset in Visual StudioStephen Kelly2018-08-221-9/+10
| | | | | | | | | | Reviewers: hans Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51079 llvm-svn: 340376
* [CodeGen] add rotate builtins that map to LLVM funnel shift Sanjay Patel2018-08-191-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial retry of rL340137 (reverted at rL340138 because of gcc host compiler crashing) with 1 change: Remove the changes to make microsoft builtins also use the LLVM intrinsics. This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang (when both halves of a funnel shift are the same value, it's a rotate). We're free to name these as we want because we're not copying gcc, but if there's some other existing art (eg, the microsoft ops) that we want to replicate, we can change the names. The funnel shift intrinsics were added here: https://reviews.llvm.org/D49242 With improved codegen in: https://reviews.llvm.org/rL337966 https://reviews.llvm.org/rL339359 And basic IR optimization added in: https://reviews.llvm.org/rL338218 https://reviews.llvm.org/rL340022 ...so these are expected to produce asm output that's equal or better to the multi-instruction alternatives using primitive C/IR ops. In the motivating loop example from PR37387: https://bugs.llvm.org/show_bug.cgi?id=37387#c7 ...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source. Differential Revision: https://reviews.llvm.org/D50924 llvm-svn: 340141
* revert r340137: [CodeGen] add rotate builtinsSanjay Patel2018-08-191-64/+0
| | | | | | At least a couple of bots (gcc host compiler on PPC only?) are showing the compiler dying while trying to compile. llvm-svn: 340138
* [CodeGen] add/fix rotate builtins that map to LLVM funnel shift (retry)Sanjay Patel2018-08-191-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a retry of rL340135 (reverted at rL340136 because of gcc host compiler crashing) with 2 changes: 1. Move the code into a helper to reduce code duplication (and hopefully work-around the crash). 2. The original commit had a formatting bug in the docs (missing an underscore). Original commit message: This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang (when both halves of a funnel shift are the same value, it's a rotate). We're free to name these as we want because we're not copying gcc, but if there's some other existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate, we can change the names. The funnel shift intrinsics were added here: https://reviews.llvm.org/D49242 With improved codegen in: https://reviews.llvm.org/rL337966 https://reviews.llvm.org/rL339359 And basic IR optimization added in: https://reviews.llvm.org/rL338218 https://reviews.llvm.org/rL340022 ...so these are expected to produce asm output that's equal or better to the multi-instruction alternatives using primitive C/IR ops. In the motivating loop example from PR37387: https://bugs.llvm.org/show_bug.cgi?id=37387#c7 ...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source. Differential Revision: https://reviews.llvm.org/D50924 llvm-svn: 340137
* revert r340135: [CodeGen] add rotate builtinsSanjay Patel2018-08-191-64/+0
| | | | | | | | At least a couple of bots (PPC only?) are showing the compiler dying while trying to compile: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/11065/steps/build%20stage%201/logs/stdio http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18267/steps/build%20stage%201/logs/stdio llvm-svn: 340136
* [CodeGen] add rotate builtinsSanjay Patel2018-08-191-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang (when both halves of a funnel shift are the same value, it's a rotate). We're free to name these as we want because we're not copying gcc, but if there's some other existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate, we can change the names. The funnel shift intrinsics were added here: D49242 With improved codegen in: rL337966 rL339359 And basic IR optimization added in: rL338218 rL340022 ...so these are expected to produce asm output that's equal or better to the multi-instruction alternatives using primitive C/IR ops. In the motivating loop example from PR37387: https://bugs.llvm.org/show_bug.cgi?id=37387#c7 ...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source. Differential Revision: https://reviews.llvm.org/D50924 llvm-svn: 340135
* [ThinLTO] Correct documentation on default number of threadsTeresa Johnson2018-08-171-1/+3
| | | | | | | | | | | | | | | | | | Summary: The number of threads used for ThinLTO backend parallelism was dropped to the number of cores in r284618 to avoid oversubscribing physical cores due to hyperthreading. This updates the documentation to reflect that change. Fixes PR38610. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50882 llvm-svn: 340021
* [ASTMatchers] Let hasAnyArgument also support CXXUnresolvedConstructExprShuai Wang2018-08-121-2/+21
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50605 llvm-svn: 339530
* [ASTMatchers] Add matchers unresolvedMemberExpr, cxxDependentScopeMemberExprShuai Wang2018-08-121-1/+26
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50606 llvm-svn: 339522
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-2/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [analyzer] Fix a typo in `RegionStore.txt`.Henry Wong2018-08-081-2/+2
| | | | | | | | | | | | | | Summary: The typo of the description for default bindings can be confusing. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D50382 llvm-svn: 339244
* [docs] Don't use the `asm` syntax highlighting (which our docs builderChandler Carruth2018-08-061-9/+9
| | | | | | | | | errors on) and clean up the formattting. This isn't actualy assembly anyways, so dropping the highlighting is probably for the best. llvm-svn: 338979
* Update docs version and clear release notes after 8.0.0 version bumpHans Wennborg2018-08-012-151/+7
| | | | llvm-svn: 338557
* UserManual: Update with the latest clang-cl flagsHans Wennborg2018-08-011-0/+21
| | | | llvm-svn: 338528
* clang-format: try to make the doc for ↵Hans Wennborg2018-07-311-9/+13
| | | | | | | | ConstructorInitializerAllOnOneLineOrOnePerLine more clear PR38080 complained that the "OnePerLine" case wasn't previously shown. llvm-svn: 338366
* [docs] UndefinedBehaviorSanitizer.rst: {,un}signed-integer-overflow: tune docsRoman Lebedev2018-07-301-2/+2
| | | | | | | | | | | | | Yes, i erroneously assumed that the "after" was meant, but i was wrong: > I really meant "performed before", for cases like 4u / -2, > where -2 is implicitly converted to UINT_MAX - 2 before > the computation. Conversions that are performed after > a computation aren't part of the computation at all, > so I think it's much clearer that they're not in scope > for this sanitizer. llvm-svn: 338306
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-302-10/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
* [OPENMP] Modify the info about OpenMP support in UsersManual, NFC.Alexey Bataev2018-07-301-7/+2
| | | | llvm-svn: 338252
* [ASTMatchers] Introduce a matcher for `ObjCIvarExpr`, support getting it's ↵George Karpenkov2018-07-271-0/+30
| | | | | | | | | | | | | declaration. ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher is required to support it. Adding a hasDeclaration support as well, as it's not very useful without it. Differential Revision: https://reviews.llvm.org/D49701 llvm-svn: 338137
* [OPENMP, DOCS] Fixed typo, NFC.Alexey Bataev2018-07-261-1/+1
| | | | llvm-svn: 338055
* [OPENMP] What's new for OpenMP in clang.Alexey Bataev2018-07-262-7/+84
| | | | | | Updated ReleaseNotes + Status of the OpenMP support in clang. llvm-svn: 338049
* [ASTMatchers] fix the missing documentation for new decltypeType matcherJonas Toth2018-07-261-0/+25
| | | | | | | | | | | | | | Summary: Regenerate the Matchers documentation, forgotten in the original patch. Reviewers: alexfh, aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49850 llvm-svn: 338022
* Fix tsan docDavid Carlier2018-07-251-0/+1
| | | | llvm-svn: 337927
* [Docs] Update supported oses for safestack, ubsan, asan, tsan and msanDavid Carlier2018-07-255-11/+14
| | | | | | Adding oses others than Linux. llvm-svn: 337926
* [clang-format ]Extend IncludeCategories regex documentationKrasimir Georgiev2018-07-252-1/+9
| | | | | | | | | | | | | | | | | | | Summary: Extend the Clang-Format IncludeCategories documentation by adding a link to the supported regular expression standard (POSIX). And extenting the example with a system header regex. [[ https://bugs.llvm.org/show_bug.cgi?id=35041 | bug 35041]] Contributed by WimLeflere! Reviewers: krasimir, Typz Reviewed By: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48827 llvm-svn: 337899
* Remove stale documentation from InternalsManual.rstErich Keane2018-07-241-5/+0
| | | | | | | The DuplicatesAllowedWhileMerging was removed a while ago, but the documentation remained. llvm-svn: 337835
* [ASTMatchers] Add an isMain() matcherGeorge Karpenkov2018-07-231-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D49615 llvm-svn: 337761
* [ASTMatchers] [NFC] Regenerate HTML docs.George Karpenkov2018-07-231-4/+4
| | | | llvm-svn: 337760
* fix typoNico Weber2018-07-201-1/+1
| | | | llvm-svn: 337620
* [CodeGen][ObjC] Make copying and disposing of a non-escaping blockAkira Hatanaka2018-07-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | no-ops. A non-escaping block on the stack will never be called after its lifetime ends, so it doesn't have to be copied to the heap. To prevent a non-escaping block from being copied to the heap, this patch sets field 'isa' of the block object to NSConcreteGlobalBlock and sets the BLOCK_IS_GLOBAL bit of field 'flags', which causes the runtime to treat the block as if it were a global block (calling _Block_copy on the block just returns the original block and calling _Block_release is a no-op). Also, a new flag bit 'BLOCK_IS_NOESCAPE' is added, which allows the runtime or tools to distinguish between true global blocks and non-escaping blocks. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D49303 llvm-svn: 337580
* Document -fobjc-weak as an extension.John McCall2018-07-201-0/+45
| | | | | | Fixes rdar://24091053. llvm-svn: 337525
* Fix and improve the ARC spec's wording about unmanaged objects.John McCall2018-07-201-19/+57
| | | | llvm-svn: 337524
* [docs] Correct -fvisibility-inlines-hidden descriptionFangrui Song2018-07-191-1/+1
| | | | llvm-svn: 337505
* [clang]: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in as the function attribute "null-pointer-is-valid"="true". This CL only adds the attribute on the function. It also strips "nonnull" attributes from function arguments but keeps the related warnings unchanged. Corresponding LLVM change rL336613 already updated the optimizations to not treat null pointer dereferencing as undefined if the attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: jyknight Subscribers: drinkcat, xbolva00, cfe-commits Differential Revision: https://reviews.llvm.org/D47894 llvm-svn: 337433
* Mention clang-cl improvements from r335466 and r336379 in ReleaseNotes.rstNico Weber2018-07-181-1/+13
| | | | llvm-svn: 337381
* Re-land r337333, "Teach Clang to emit address-significance tables.",Peter Collingbourne2018-07-182-0/+17
| | | | | | | | | | | | | | | | | | | | | which was reverted in r337336. The problem that required a revert was fixed in r337338. Also added a missing "REQUIRES: x86-registered-target" to one of the tests. Original commit message: > Teach Clang to emit address-significance tables. > > By default, we emit an address-significance table on all ELF > targets when the integrated assembler is enabled. The emission of an > address-significance table can be controlled with the -faddrsig and > -fno-addrsig flags. > > Differential Revision: https://reviews.llvm.org/D48155 llvm-svn: 337339
* Revert r337333, "Teach Clang to emit address-significance tables."Peter Collingbourne2018-07-172-17/+0
| | | | | | | | | Causing multiple failures on sanitizer bots due to TLS symbol errors, e.g. /usr/bin/ld: __msan_origin_tls: TLS definition in /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/lib/clang/7.0.0/lib/linux/libclang_rt.msan-powerpc64.a(msan.cc.o) section .tbss.__msan_origin_tls mismatches non-TLS reference in /tmp/lit_tmp_0a71tA/mallinfo-3ca75e.o llvm-svn: 337336
* Teach Clang to emit address-significance tables.Peter Collingbourne2018-07-172-0/+17
| | | | | | | | | | | By default, we emit an address-significance table on all ELF targets when the integrated assembler is enabled. The emission of an address-significance table can be controlled with the -faddrsig and -fno-addrsig flags. Differential Revision: https://reviews.llvm.org/D48155 llvm-svn: 337333
* [ASTMatchers] Introduce Objective-C matchers `hasReceiver` and ↵George Karpenkov2018-07-161-0/+25
| | | | | | | | `isInstanceMessage` for ObjCMessageExpr Differential Revision: https://reviews.llvm.org/D49333 llvm-svn: 337209
* SafeStack: Add builtins to read unsafe stack top/bottomVlad Tsyrklevich2018-07-131-2/+14
| | | | | | | | | | | | | | | | | | | | Summary: Introduce built-ins to read the unsafe stack top and bottom. The unsafe stack top is required to implement garbage collection scanning for Oilpan. Currently there is already a built-in 'get_unsafe_stack_start' to read the bottom of the unsafe stack, but I chose to duplicate this API because 'start' is ambiguous (e.g. Oilpan uses WTF::GetStackStart to read the safe stack top.) Reviewers: pcc Reviewed By: pcc Subscribers: llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D49152 llvm-svn: 337037
* [NFC] Rename clang::AttributeList to clang::ParsedAttrErich Keane2018-07-131-6/+6
| | | | | | | Since The type no longer contains the 'next' item anymore, it isn't a list, so rename it to ParsedAttr to be more accurate. llvm-svn: 337005
* [docs] List correct default for -ftemplate-depth; also add missingRichard Smith2018-07-111-1/+6
| | | | | | documentation for -fconstexpr-steps. llvm-svn: 336747
* [ASTMatchers] A matcher for Objective-C @autoreleasepoolGeorge Karpenkov2018-07-061-8/+66
| | | | | | Differential Revision: https://reviews.llvm.org/D48910 llvm-svn: 336468
* The :option: syntax was generating Sphinx build warnings; switched to double ↵Aaron Ballman2018-06-281-3/+2
| | | | | | backticks to silence the warning; NFC. llvm-svn: 335843
* Correct the code highlighting marker to be Objective-C rather than C++ which ↵Aaron Ballman2018-06-281-1/+1
| | | | | | fixes a Sphinx build warning; NFC. llvm-svn: 335842
* [UBSan] Add silence_unsigned_overflow flag.Matt Morehouse2018-06-271-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO reports. This feature, combined with -fsanitize-recover=unsigned-integer-overflow, is useful for providing fuzzing signal without the excessive log output. Helps with https://github.com/google/oss-fuzz/issues/910. Reviewers: kcc, vsk Reviewed By: vsk Subscribers: vsk, kubamracek, Dor1s, llvm-commits Differential Revision: https://reviews.llvm.org/D48660 llvm-svn: 335762
* Implement CFI for indirect calls via a member function pointer.Peter Collingbourne2018-06-262-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 llvm-svn: 335569
* ASan docs: no_sanitize("address") works on globals.Evgeniy Stepanov2018-06-211-5/+9
| | | | | | | | | | | | Summary: Mention that no_sanitize attribute can be used with globals. Reviewers: alekseyshl Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48390 llvm-svn: 335193
* [docs] -fsanitize=cfi only allowed with -fvisibility=Fangrui Song2018-06-151-1/+1
| | | | llvm-svn: 334870
* clang-format: Fix documentation generationFrancois Ferrand2018-06-141-19/+21
| | | | | | | | | | | | | | | | | | | | Summary: It seems that the changes done to `ClangFormatStyleOptions.rst` @334408 are causing the generation of the documentation to fail, with the following error: Warning, treated as error: /llvm/tools/clang/docs/ClangFormatStyleOptions.rst:1060: WARNING: Definition list ends without a blank line; unexpected unindent. This is due to missing indent in some code block, and fixed by this patch. Reviewers: krasimir, djasper, klimek Reviewed By: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48161 llvm-svn: 334709
OpenPOWER on IntegriCloud