summaryrefslogtreecommitdiffstats
path: root/clang/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [Remarks][Driver] Place temporary remark files next to temporary object filesFrancis Visoiu Mistrih2019-12-181-9/+28
| | | | | | | | | | | On Darwin, when used for generating a linked binary from a source file (through an intermediate object file), the driver will invoke `cc1` to generate a temporary object file. The temporary remark file will now be emitted next to the object file, which will then be picked up by `dsymutil` and emitted in the .dSYM bundle. This is available for all formats except YAML since by default, YAML doesn't need a section and the remark file will be lost.
* [Docs] Fix indentation in remarks sectionFrancis Visoiu Mistrih2019-12-181-19/+19
|
* [OPENMP][DOCS]Claim simd nontemporal clause, NFC.Alexey Bataev2019-12-161-1/+1
|
* [OPENMP][DOCS]Mark if clause on simd done, NFC.Alexey Bataev2019-12-161-1/+1
|
* [OpenMP][Docs] Claim loop tiling.Michael Kruse2019-12-131-0/+2
|
* [Driver] Use .init_array for all gcc installations and simplify Generic_ELF ↵Fangrui Song2019-12-131-0/+4
| | | | | | | | | | | | | | | | | -fno-use-init-array rules D39317 made clang use .init_array when no gcc installations is found. This change changes all gcc installations to use .init_array . GCC 4.7 by default stopped providing .ctors/.dtors compatible crt files, and stopped emitting .ctors for __attribute__((constructor)). .init_array should always work. FreeBSD rules are moved to FreeBSD.cpp to make Generic_ELF rules clean. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71434
* Call objc_retainBlock before passing a block as a variadic argumentAkira Hatanaka2019-12-131-0/+6
| | | | | | | | | Copy the block to the heap before passing it to the callee in case the block escapes in the callee. rdar://problem/55683462 Differential Revision: https://reviews.llvm.org/D71431
* Correct inf typoAndrew Gaul2019-12-131-1/+1
| | | | | | | | | | | | Reviewers: krasimir Reviewed By: krasimir Subscribers: Jim, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57732
* Fix an error in the block ABI documentation sample codeAkira Hatanaka2019-12-111-1/+1
| | | | rdar://problem/38663011
* [OpenMP][Docs] Mark 5.0 features worked on and list 5.1 featuresJohannes Doerfert2019-12-121-2/+17
|
* [Remarks][Docs] Enhance documentation for opt-remarks driver optionsFrancis Visoiu Mistrih2019-12-102-14/+51
| | | | | Add better documentation about the naming scheme, add a few more explicit descriptions and make the sphinx look better.
* [Remarks][Driver] Error on -foptimization-record-file with multiple -arch ↵Francis Visoiu Mistrih2019-12-091-1/+1
| | | | | | | | | options This adds a check for the usage of -foptimization-record-file with multiple -arch options. This is not permitted since it would require us to rename the file requested by the user to avoid overwriting it for the second cc1 invocation.
* Fix typo in the AST Matcher Reference doc Closes: #54Sylvestre Ledru2019-12-081-1/+1
|
* [OPENMP][DOCS]Update list of the supported features, NFC.Alexey Bataev2019-12-051-3/+3
|
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-051-4/+50
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-041-50/+4
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* [OPENMP]Update list of implemented features, NFC.Alexey Bataev2019-12-041-5/+5
|
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-041-4/+50
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* [Coverage] Emit a gap region to cover switch bodiesVedant Kumar2019-12-031-0/+34
| | | | | | | | | | | | | | Emit a gap region beginning where the switch body begins. This sets line execution counts in the areas between non-overlapping cases to 0. This also removes some special handling of the first case in a switch: these are now treated like any other case. This does not resolve an outstanding issue with case statement regions that do not end when a region is terminated. But it should address llvm.org/PR44011. Differential Revision: https://reviews.llvm.org/D70571
* [clang-format] Add new option to add spaces around conditionsMitchell Balan2019-12-031-0/+3
| | | | | | | | | | | | | | | Summary: This diff adds a new option SpacesAroundConditions that inserts spaces inside the braces for conditional statements. Reviewers: klimek, owenpan, mitchell-stellar, MyDeveloperDay Patch by: timwoj Subscribers: rsmmr, cfe-commits Tags: clang, clang-format Differential Revision: https://reviews.llvm.org/D68346
* Revert "[ARM] Allocatable Global Register Variables for ARM"Carey Williams2019-11-291-21/+0
| | | | This reverts commit 2d739f98d8a53e38bf9faa88cdb6b0c2a363fb77.
* [ConstExprPreter] Removed the flag forcing the use of the interpreterNandor Licker2019-11-271-2/+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-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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
* Revert "[clang][CodeGen] Implicit Conversion Sanitizer: handle ↵Roman Lebedev2019-11-271-4/+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.
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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
* [analyzer][docs] NFC: Extend documentation for MallocOverflow checkerBorsik Gabor2019-11-231-0/+6
| | | | | | Patch by Benics Balázs Differential Revision: https://reviews.llvm.org/D70596
* [OPENMP] [DOCS] correct status for use_device_addr clauseKelvin Li2019-11-221-1/+1
| | | | | | The status of the use_device_addr clause feature is changed from 'done' to 'worked on`. Differential Revision: https://reviews.llvm.org/D70608
* Atomics: support min/max orthogonallyTim Northover2019-11-211-0/+2
| | | | | | | | | | | | We seem to have been gradually growing support for atomic min/max operations (exposing longstanding IR atomicrmw instructions). But until now there have been gaps in the expected intrinsics. This adds support for the C11-style intrinsics (i.e. taking _Atomic, rather than individually blessed by C11 standard), and the variants that return the new value instead of the original one. That way, people won't be misled by trying one form and it not working, and the front-end is more friendly to people using _Atomic types, as we recommend.
* [clang-format] [NFC] add recent changes to release notesmydeveloperday2019-11-191-12/+30
| | | | | | | | | | | | | | Summary: clang-tidy keeps nice release notes of what is added, have clang-format do the same. Reviewers: klimek, mitchell-stellar, sylvestre.ledru, sammccall Reviewed By: mitchell-stellar Subscribers: merge_guards_bot, Eugene.Zelenko, cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D70355
* [profile] Support online merging with continuous sync modeVedant Kumar2019-11-181-6/+5
| | | | | | | | | | | | | | | Make it possible to use online profile merging ("%m" mode) with continuous sync ("%c" mode). To implement this, the merged profile is locked in the runtime initialization step and either a) filled out for the first time or b) checked for compatibility. Then, the profile can simply be mmap()'d with MAP_SHARED set. With the mmap() in place, counter updates from every process which uses an image are mapped onto the same set of physical pages assigned by the filesystem cache. After the mmap() is set up, the profile is unlocked. Differential Revision: https://reviews.llvm.org/D69586
* Temporarily Revert "Add support for options -frounding-math, ftrapping-math, ↵Eric Christopher2019-11-181-50/+4
| | | | | | | | -ffp-model=, and -ffp-exception-behavior=" and a follow-up NFC rearrangement as it's causing a crash on valid. Testcase is on the original review thread. This reverts commits af57dbf12e54f3a8ff48534bf1078f4de104c1cd and e6584b2b7b2de06f1e59aac41971760cac1e1b79
* [RISCV] Set triple based on -march flagSimon Cook2019-11-181-1/+2
| | | | | | | | | For RISC-V the value provided to -march should determine whether to compile for 32- or 64-bit RISC-V irrespective of the target provided to the Clang driver. This adds a test for this flag for RISC-V and sets the Target architecture correctly in these cases. Differential Revision: https://reviews.llvm.org/D54214
* [ARM] Allocatable Global Register Variables for ARMAnna Welker2019-11-181-0/+21
| | | | | | | | | | | | Provides support for using r6-r11 as globally scoped register variables. This requires a -ffixed-rN flag in order to reserve rN against general allocation. If for a given GRV declaration the corresponding flag is not found, or the the register in question is the target's FP, we fail with a diagnostic. Differential Revision: https://reviews.llvm.org/D68862
* [clang-format] Add SpaceBeforeBracketsmydeveloperday2019-11-161-0/+18
| | | | | | | | | | | | | | | | Summary: Adds a new option SpaceBeforeBrackets to add spaces before brackets (i.e. int a[23]; -> int a [23];) This is present as an option in the Visual Studio C++ code formatting settings, but there was no matching setting in clang-format. Reviewers: djasper, MyDeveloperDay, mitchell-stellar Reviewed By: MyDeveloperDay Subscribers: llvm-commits, cfe-commits, klimek Patch by: Anteru Tags: #clang, #clang-format, #llvm Differential Revision: https://reviews.llvm.org/D6920
* [RISCV] Match GCC `-march`/`-mabi` driver defaultsSam Elliott2019-11-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang/LLVM is a cross-compiler, and so we don't have to make a choice about `-march`/`-mabi` at build-time, but we may have to compute a default `-march`/`-mabi` when compiling a program. Until now, each place that has needed a default `-march` has calculated one itself. This patch adds a single place where a default `-march` is calculated, in order to avoid calculating different defaults in different places. This patch adds a new function `riscv::getRISCVArch` which encapsulates this logic based on GCC's for computing a default `-march` value when none is provided. This patch also updates the logic in `riscv::getRISCVABI` to match the logic in GCC's build system for computing a default `-mabi`. This patch also updates anywhere that `-march` is used to now use the new function which can compute a default. In particular, we now explicitly pass a `-march` value down to the gnu assembler. GCC has convoluted logic in its build system to choose a default `-march`/`-mabi` based on build options, which would be good to match. This patch is based on the logic in GCC 9.2.0. This commit's logic is different to GCC's only for baremetal targets, where we default to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple. Tests have been updated to match the new logic. Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen Reviewed By: asb, luismarques Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69383
* Allow additional file suffixes/extensions considered as source in main ↵mydeveloperday2019-11-123-3/+41
| | | | | | | | | | | | | | | | | | | | | include grouping Summary: By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code. For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files. On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename. Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: MyDeveloperDay, cfe-commits Patch by: furdyna Tags: #clang Differential Revision: https://reviews.llvm.org/D67750
* clang-format: fix a typo introduced by the previous changeSylvestre Ledru2019-11-111-1/+1
|
* clang-format: refresh the list of optionsSylvestre Ledru2019-11-081-45/+52
|
* clang-format: Add to the release notes the new --dry-run/-n optionSylvestre Ledru2019-11-081-0/+3
|
* [clang-format] NFC allow Format.h to be clang-formatted but still maintain ↵paul_hoad2019-11-081-2/+3
| | | | | | | | | | | | | | | | | | | | | the same doc layout in ClangFormatStyleOptions.rst Summary: Format.h is used to generate ClangFormatStyleOptions.rst, the layout of the comments is critical to the rst file. Accidentally clang-formatting Format.h can lead to the .rst changing. This revision simply add // clang-format off/on statement around the areas who formatting needs to be maintained, mainly around the options that are related to what happens when the line breaks due to `ColumnLimit` (which is what is happening to the comment) This allows Format.h to be clang-formatted without causing a change in the documentation when dump_format_style.py is rerun, which is also part of the revision. Reviewers: mitchell-stellar, klimek, sammccall, owenpan Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D69951
* [clang-format] Ensure dump_format_style.py can generate ↵paul_hoad2019-11-082-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | ClangFormatStyleOptions.rst without manual intervention Summary: This revision is the last in a series of revisions to return `clang/doc/tools/dump_format_style.py` to be being able to parse Format.h without needing to manually merge the ClangFormatStyleOptions.rst file. The final modification to dump_format_style.py is needed following the addition of a nested enumeration inside a nested structure following the introduction of {D68296} Prior related revisions will allow for a fully clang-formatted `clang/include/clang/Format/Format.h` to once again be used at the source. {D69951} {D69433} {D69404} Reviewers: mitchell-stellar, klimek, sammccall, owenpan Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D70003
* [OPENMP][DOCS] Update OpenMP status (NFC)Alexey Bataev2019-11-071-2/+4
| | | | | | | | | | | | | | Summary: This is updating the OpenMP status table. Cray has volunteered for `defaultmap` and supporting `in_reduction` on the `target` construct, so the status on those entries from was changed from "unclaimed". Also, a new entry was added for supporting non-contiguous arrays sections on the `target update` directive. Reviewers: ABataev, hfinkel, jdoerfert, kkwli0 Reviewed By: ABataev Subscribers: guansong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69923
* Add support for options -frounding-math, ftrapping-math, -ffp-model=, and ↵Melanie Blower2019-11-071-4/+50
| | | | | | | | | | | | -ffp-exception-behavior= Add options to control floating point behavior: trapping and exception behavior, rounding, and control of optimizations that affect floating point calculations. More details in UsersManual.rst. Reviewers: rjmccall Differential Revision: https://reviews.llvm.org/D62731
* [OPENMP] [DOCS] fix section formatting issues [NFC]Kelvin Li2019-11-061-13/+10
| | | | Differential Revision: https://reviews.llvm.org/D69909
* [clang-format] [NFC] update the documentation in Format.h to allow ↵paulhoad2019-11-062-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dump_format_style.py to get a little closer to being correct. (part 2) Summary: a change {D67541} cause LanguageStandard to now be subtly different from all other clang-format options, in that the Enum value (less the prefix) is not always allowed as valid as the configuration option. This caused the ClangFormatStyleOptions.rst and the Format.h to diverge so that the ClangFormatStyleOptions.rst could no longer be generated from the Format.h using dump_format_stlye.py This fix tried to remedy that: 1) by allowing an additional comment (in Format.h) after the enum to be used as the `in configuration ( XXXX )` text, and changing the dump_format_style.py to support that. This makes the following code: ``` enum { ... LS_Cpp03, // c++03 LS_Cpp11, // c++11 ... }; ``` would render as: ```* ``LS_Cpp03`` (in configuration: ``c++03``) * ``LS_Cpp11`` (in configuration: ``c++11``) ``` And we also move the deprecated alias into the text of the enum (otherwise it won't be added at the end as an option) This patch includes a couple of other whitespace changes which help bring Format.h and ClangFormatStyleOptions.rst almost back into line and regeneratable... (there is still one more) Reviewers: klimek, mitchell-stellar, sammccall Reviewed By: mitchell-stellar, sammccall Subscribers: mrexodia, cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D69433
* [OPENMP][DOCS]Fix coloring of the implemented features status, NFC.Alexey Bataev2019-11-051-5/+5
|
* [OPENMP][DOCS]Update list of implemented features, NFC.Alexey Bataev2019-11-041-2/+2
|
* Add release notes for commit ccc4d83cda16bea1d9dfd0967dc7d2cfb24b8e75.James Y Knight2019-11-041-1/+43
| | | | | (Which was "[ObjC] Diagnose implicit type coercion from ObjC 'Class' to object pointer types.")
* [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gccCraig Topper2019-11-041-0/+4
| | | | | | | | | | | | | | | | | -mvzeroupper will force the vzeroupper insertion pass to run on CPUs that normally wouldn't. -mno-vzeroupper disables it on CPUs where it normally runs. To support this with the default feature handling in clang, we need a vzeroupper feature flag in X86.td. Since this flag has the opposite polarity of the fast-partial-ymm-or-zmm-write we used to use to disable the pass, we now need to add this new flag to every CPU except KNL/KNM and BTVER2 to keep identical behavior. Remove -fast-partial-ymm-or-zmm-write which is no longer used. Differential Revision: https://reviews.llvm.org/D69786
* [profile] Add a mode to continuously sync counter updates to a fileVedant Kumar2019-10-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for continuously syncing profile counter updates to a file. The motivation for this is that programs do not always exit cleanly. On iOS, for example, programs are usually killed via a signal from the OS. Running atexit() handlers after catching a signal is unreliable, so some method for progressively writing out profile data is necessary. The approach taken here is to mmap() the `__llvm_prf_cnts` section onto a raw profile. To do this, the linker must page-align the counter and data sections, and the runtime must ensure that counters are mapped to a page-aligned offset within a raw profile. Continuous mode is (for the moment) incompatible with the online merging mode. This limitation is lifted in https://reviews.llvm.org/D69586. Continuous mode is also (for the moment) incompatible with value profiling, as I'm not sure whether there is interest in this and the implementation may be tricky. As I have not been able to test extensively on non-Darwin platforms, only Darwin support is included for the moment. However, continuous mode may "just work" without modification on Linux and some UNIX-likes. AIUI the default value for the GNU linker's `--section-alignment` flag is set to the page size on many systems. This appears to be true for LLD as well, as its `no_nmagic` option is on by default. Continuous mode will not "just work" on Fuchsia or Windows, as it's not possible to mmap() a section on these platforms. There is a proposal to add a layer of indirection to the profile instrumentation to support these platforms. rdar://54210980 Differential Revision: https://reviews.llvm.org/D68351
OpenPOWER on IntegriCloud