summaryrefslogtreecommitdiffstats
path: root/clang/docs/ReleaseNotes.rst
Commit message (Collapse)AuthorAgeFilesLines
* add release notes for ffp-model and ffp-exception-behaviorMelanie Blower2020-04-161-0/+7
| | | | (cherry picked from commit c8dadac228b7dd3a71d5fc25489d1b884a2b0f5e)
* clang/release notes: s/Subversion/git/Sylvestre Ledru2020-03-221-1/+1
|
* add a missing dash to the release notesHans Wennborg2020-03-131-1/+1
|
* add a few new warnings to the 10.0 clang release notesNico Weber2020-03-131-0/+22
|
* clang-format release notes: Document the improvement with the ↵Sylvestre Ledru2020-03-051-0/+2
| | | | | | AlwaysBreakAfterReturnType option See https://reviews.llvm.org/D69573
* ReleaseNotes: Formatting and typo fixes.Peter Wu2020-03-041-31/+31
|
* Add C standard upgrade in clang-11 release noteNick Desaulniers2020-03-021-0/+6
| | | | | | | | | | | | | | Summary: As per rsmith (https://reviews.llvm.org/D75383). Reviewers: hans Reviewed By: hans Subscribers: cfe-commits, rsmith Tags: #clang Differential Revision: https://reviews.llvm.org/D75469
* Minor ReleaseNotes fixesHans Wennborg2020-03-021-33/+33
|
* ReleaseNotes: remove in-progress warnings, tidy up a bitHans Wennborg2020-02-281-68/+16
|
* [ReleaseNotes] Add some items for clangFangrui Song2020-02-271-0/+8
|
* [ReleaseNotes] Add OpenCL release notesSven van Haastregt2020-02-271-3/+26
| | | | Differential Revision: https://reviews.llvm.org/D75125
* [ReleaseNotes] Fix typosSven van Haastregt2020-02-271-2/+2
|
* [ReleaseNotes] Mention -fmacro-prefix-map and -ffile-prefix-map.Peter Wu2020-02-271-0/+6
| | | | Differential revision: https://reviews.llvm.org/D75012
* [RISCV] Add Clang and LLVM Release NotesSam Elliott2020-02-261-0/+21
|
* [docs][WebAssembly] WebAssembly-specific release notes for 10.0.Dan Gohman2020-02-251-0/+3
|
* Add Control Flow Guard in Clang release notes.Hans Wennborg2020-02-251-0/+6
| | | | | | By Andrew Paverd! Differential revision: https://reviews.llvm.org/D75047
* Add -debug-info-kind=constructor to clang release notesAmy Huang2020-02-241-0/+4
|
* ReleaseNotes: ARM and AArch64Hans Wennborg2020-02-241-1/+1
| | | | By Kristof Beyls!
* ReleaseNotes: OpenMPHans Wennborg2020-02-241-1/+19
| | | | By Alexey Bataev!
* [docs] Add -Wmisleading-indentation to clang's release notes.Tyker2020-02-221-0/+4
|
* [analyzer] Add 10.0.0 release notes.Hans Wennborg2020-02-101-4/+18
| | | | | | Differential revision: https://reviews.llvm.org/D73966 By Kristóf Umann!
* [clang] Add release notes for the 10.x branch for things I've doneMartin Storsjö2020-02-051-0/+6
| | | | Differential Revision: https://reviews.llvm.org/D74028
* Update for Clang 10 release notes in order to have reference to D66404.Andi-Bogdan Postelnicu2020-02-051-1/+18
| | | | | | | | | | | | Summary: Since `D66404` adds some significat modifications to the `CFG` we should include it in the release notes. Reviewers: hans Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74031
* Add -Wrange-loop-analysis changes to ReleaseNotesMark de Wever2020-02-041-1/+3
| | | | | | This reflects the recent changes done. Differential Revision: https://reviews.llvm.org/D73834
* [docs][mips] 10.0 Release notesSimon Atanasyan2020-01-261-0/+3
| | | | | | MIPS specific part of LLVM 10.0 Release notes for LLVM, Clang and LLD. Differential Revision: https://reviews.llvm.org/D73108
* [Concepts] Add Concepts to ReleaseNotes.rstSaar Raz2020-01-241-1/+10
| | | | | | Concepts support has been ported to the 10.x release. Add information about the feature to the release notes.
* Update documentation and release notes to match the state ofRichard Smith2020-01-231-15/+16
| | | | -flax-vector-conversions on the Clang 10 release branch.
* PR17164: Change clang's default behavior from -flax-vector-conversions=all ↵Richard Smith2020-01-171-0/+24
| | | | | | | | | | | | | | | | | | to -flax-vector-conversions=integer. Summary: See proposal on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html Reviewers: SjoerdMeijer, eli.friedman Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67678 (cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
* Replace CLANG_SPAWN_CC1 env var with a driver mode flagNico Weber2020-01-161-0/+5
| | | | | | | | | | | | | | | | | | Flags are clang's default UI is flags. We can have an env var in addition to that, but in D69825 nobody has yet mentioned why this needs an env var, so omit it for now. If someone needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1 for example). Also mention the cc1-in-process change in the release notes. Also spruce up the test a bit so it actually tests something :) Differential Revision: https://reviews.llvm.org/D72769 (cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
* Add -Wrange-loop-analysis changes to ReleaseNotesMark de Wever2020-01-111-0/+4
| | | | This reflects the recent changes done.
* [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
* [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
* [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
* [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
* [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-121-0/+18
| | | | | | | | | | | | | | | | | | | | | 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: Add to the release notes the new --dry-run/-n optionSylvestre Ledru2019-11-081-0/+3
|
* 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
* 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
* 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
* 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-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-101-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Try to fix sphinx indentation errorSimon Pilgrim2019-10-051-3/+5
| | | | llvm-svn: 373831
* [ClangFormat] relnotes for r373439Sam McCall2019-10-021-1/+9
| | | | llvm-svn: 373441
* [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
* Add a release note for r372844Hans Wennborg2019-09-251-1/+12
| | | | llvm-svn: 372846
OpenPOWER on IntegriCloud