summaryrefslogtreecommitdiffstats
path: root/clang/docs/ReleaseNotes.rst
Commit message (Collapse)AuthorAgeFilesLines
...
* Support for groups of attributes in #pragma clang attributeErik Pilkington2018-10-291-2/+2
| | | | | | | | | | | | | | | | | | This commit enables pushing an empty #pragma clang attribute push, then adding multiple attributes to it, then popping them all with #pragma clang attribute pop, just like #pragma clang diagnostic. We still support the current way of adding these, #pragma clang attribute push(__attribute__((...))), by treating it like a combined push/attribute. This is needed to create macros like: DO_SOMETHING_BEGIN(attr1, attr2, attr3) // ... DO_SOMETHING_END rdar://45496947 Differential revision: https://reviews.llvm.org/D53621 llvm-svn: 345486
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-0/+20
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* Add a flag to remap manglings when reading profile data information.Richard Smith2018-10-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This can be used to preserve profiling information across codebase changes that have widespread impact on mangled names, but across which most profiling data should still be usable. For example, when switching from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI, or even from a 32-bit to a 64-bit build. The user can provide a remapping file specifying parts of mangled names that should be treated as equivalent (eg, std::__1 should be treated as equivalent to std::__cxx11), and profile data will be treated as applying to a particular function if its name is equivalent to the name of a function in the profile data under the provided equivalences. See the documentation change for a description of how this is configured. Remapping is supported for both sample-based profiling and instruction profiling. We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately. Support is only added for the new pass manager. If someone wants to also add support for this for the old pass manager, doing so should be straightforward. llvm-svn: 344199
* [clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstopMike Rice2018-09-111-0/+5
| | | | | | | | | | | | | With clang-cl, when the user specifies /Yc or /Yu without a filename the compiler uses a #pragma hdrstop in the main source file to determine the end of the PCH. If a header is specified with /Yc or /Yu #pragma hdrstop has no effect. The optional #pragma hdrstop filename argument is not yet supported. Differential Revision: https://reviews.llvm.org/D51391 llvm-svn: 341963
* ReleaseNotes: update links to use httpsHans Wennborg2018-09-101-9/+9
| | | | llvm-svn: 341786
* Update docs version and clear release notes after 8.0.0 version bumpHans Wennborg2018-08-011-149/+5
| | | | llvm-svn: 338557
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-301-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, DOCS] Fixed typo, NFC.Alexey Bataev2018-07-261-1/+1
| | | | llvm-svn: 338055
* [OPENMP] What's new for OpenMP in clang.Alexey Bataev2018-07-261-1/+15
| | | | | | Updated ReleaseNotes + Status of the OpenMP support in clang. llvm-svn: 338049
* fix typoNico Weber2018-07-201-1/+1
| | | | llvm-svn: 337620
* 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-181-0/+8
| | | | | | | | | | | | | | | | | | | | | 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-171-8/+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-171-0/+8
| | | | | | | | | | | 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
* 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
* Add -fforce-emit-vtablesPiotr Padlewski2018-06-131-0/+6
| | | | | | | | | | | | | | | | | | | Summary: In many cases we can't devirtualize because definition of vtable is not present. Most of the time it is caused by inline virtual function not beeing emitted. Forcing emitting of vtable adds a reference of these inline virtual functions. Note that GCC was always doing it. Reviewers: rjmccall, rsmith, amharc, kuhar Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D47108 Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com> llvm-svn: 334600
* [diagtool] Add diagtool to install target.Jonas Devlieghere2018-05-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | Although not very well known, diagtool is an incredibly convenient utility for dealing with diagnostics. Particularly useful are the "tree" and "show-enabled" commands: - The former prints the hierarchy of diagnostic (warning) flags and which of them are enabled by default. - The latter can be used to replace an invocation to clang and will print which diagnostics are disabled, warnings or errors. For instance: `diagtool show-enabled -Wall -Werror /tmp/test.c` will print that -Wunused-variable (warn_unused_variable) will be treated as an error. This patch adds them to the install target so it gets shipped with the LLVM release. It also adds a very basic man page and mentions this change in the release notes. Differential revision: https://reviews.llvm.org/D46694 llvm-svn: 332448
* [Documentation] Fix Release Notes format issues.Eugene Zelenko2018-05-151-7/+8
| | | | llvm-svn: 332405
* [clang-format] Add raw string formatting to release notesKrasimir Georgiev2018-05-081-0/+4
| | | | | | | | | | | | Reviewers: hans Reviewed By: hans Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46572 llvm-svn: 331750
* Non-zero-length bit-fields make a class non-empty.Richard Smith2018-05-071-0/+9
| | | | | | | | | | | | | | | | | | | | This implements the rule intended by the standard (see LWG 2358) and the rule intended by the Itanium C++ ABI (see https://github.com/itanium-cxx-abi/cxx-abi/pull/51), and makes Clang match the behavior of GCC, ICC, and MSVC. A pedantic reading of both the standard and the ABI indicate that Clang is currently technically correct, but that's not worth much when it's clear that the wording is wrong in both those places. This is an ABI break for classes that derive from a class that is empty other than one or more unnamed non-zero-length bit-fields. Such cases are expected to be rare, but -fclang-abi-compat=6 restores the old behavior just in case. Differential Revision: https://reviews.llvm.org/D45174 llvm-svn: 331620
* [Driver, CodeGen] rename options to disable an FP cast optimizationSanjay Patel2018-04-301-8/+7
| | | | | | | | | | | | | | As suggested in the post-commit thread for rL331056, we should match these clang options with the established vocabulary of the corresponding sanitizer option. Also, the use of 'strict' is well-known for these kinds of knobs, and we can improve the descriptive text in the docs. So this intends to match the logic of D46135 but only change the words. Matching LLVM commit to match this spelling of the attribute to follow shortly. Differential Revision: https://reviews.llvm.org/D46236 llvm-svn: 331209
* PR37275 packed attribute should not apply to base classesRichard Smith2018-04-291-0/+6
| | | | | | | | | | | | | Clang incorrectly applied the packed attribute to base classes. Per GCC's documentation and as can be observed from its behavior, packed only applies to members, not base classes. This change is conditioned behind -fclang-abi-compat so that an ABI break can be avoided by users if desired. Differential Revision: https://reviews.llvm.org/D46218 llvm-svn: 331136
* [docs] more dashesSanjay Patel2018-04-271-1/+1
| | | | llvm-svn: 331057
* [docs] add -ffp-cast-overflow-workaround to the release notesSanjay Patel2018-04-271-0/+9
| | | | | | | | | This option was added with: D46135 rL331041 ...copying the text from UsersManual.rst for more exposure. llvm-svn: 331056
* [Sema] Add -Wno-self-assign-overloadedRoman Lebedev2018-04-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It seems there isn't much enthusiasm for `-wtest` D45685. This is more conservative version, which i had in the very first revision of D44883, but that 'erroneously' got removed because of the review. **Based on some [irc] discussions, it must really be documented that we want all the new diagnostics to have their own flags, to ease rollouts, transitions, etc.** Please do note that i'm only adding `-Wno-self-assign-overloaded`, but not `-Wno-self-assign-field-overloaded`, because i'm honestly not aware of any false-positives from the `-field` variant, but i can just as easily add it if wanted. https://reviews.llvm.org/D44883#1068561 Reviewers: dblaikie, aaron.ballman, thakis, rjmccall, rsmith Reviewed By: dblaikie Subscribers: Quuxplusone, chandlerc, cfe-commits Differential Revision: https://reviews.llvm.org/D45766 llvm-svn: 330651
* [CUDA] Document recent changesJonas Hahnfeld2018-04-201-0/+12
| | | | | | | | | * Finding installations via ptxas binary * Relocatable device code Differential Revision: https://reviews.llvm.org/D45449 llvm-svn: 330426
* [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded ↵Roman Lebedev2018-04-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | self-assignment (classes) Summary: This has just bit me, so i though it would be nice to avoid that next time :) Motivational case: https://godbolt.org/g/cq9UNk Basically, it's likely to happen if you don't like shadowing issues, and use `-Wshadow` and friends. And it won't be diagnosed by clang. The reason is, these self-assign diagnostics only work for builtin assignment operators. Which makes sense, one could have a very special operator=, that does something unusual in case of self-assignment, so it may make sense to not warn on that. But while it may be intentional in some cases, it may be a bug in other cases, so it would be really great to have some diagnostic about it... Reviewers: aaron.ballman, rsmith, rtrieu, nikola, rjmccall, dblaikie Reviewed By: rjmccall Subscribers: EricWF, lebedev.ri, thakis, Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D44883 llvm-svn: 329493
* DR1672, DR1813, DR1881, DR2120: Implement recent fixes to "standardRichard Smith2018-04-051-0/+5
| | | | | | | | | | | | | | | | | layout" rules. The new rules say that a standard-layout struct has its first non-static data member and all base classes at offset 0, and consider a class to not be standard-layout if that would result in multiple subobjects of a single type having the same address. We track "is C++11 standard-layout class" separately from "is standard-layout class" so that the ABIs that need this information can still use it. Differential Revision: https://reviews.llvm.org/D45176 llvm-svn: 329332
* As we don't use minor version anymore, let's remove it from the release ↵Sylvestre Ledru2018-04-041-2/+2
| | | | | | notes too llvm-svn: 329161
* Use Clang when referring to the project and clang when referring to the binary.Richard Smith2018-04-031-2/+3
| | | | llvm-svn: 329098
* Rename clang link from clang-X.Y to clang-XSylvestre Ledru2018-03-291-0/+3
| | | | | | | | | | | | | | | | | | | Summary: As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version. So, instead, I propose the following: Instead of having clang-7.0 in bin/, we will have clang-7 Since also matches was gcc is doing. Reviewers: tstellar, dlj, dim, hans Reviewed By: dim, hans Subscribers: dim, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D41808 llvm-svn: 328769
* [docs] ReleaseNotes: document -Wextra-semi changes.Roman Lebedev2018-03-161-1/+7
| | | | | | | | | I should have done it in rL327558 / D43162, but forgot.. I'm not 100% sure about the text, but i don't think it warrants a whole new differential revision. llvm-svn: 327725
* [Documentation] Fix Release notes problems introduced in r326889. Add ↵Eugene Zelenko2018-03-081-5/+7
| | | | | | highlighting. llvm-svn: 326979
* Add Clang ReleaseNotes that --autocomplete breaks backward compatibilyYuka Takahashi2018-03-071-0/+9
| | | | | | | | | | | | | | Summary: --autocomplete flag now handles all the flags passed to shell, and this implementation breaks backward compatibily before Clang 6.0. Reviewers: teemperor, v.g.vassilev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44191 llvm-svn: 326889
* Document attribute target multiversioning.Erich Keane2018-01-081-0/+6
| | | | | | | | | | Add attribute target multiversioning to the release notes. Additionally adds multiversioning support to the attribute documentation for 'target'. Differential Revision: https://reviews.llvm.org/D41837 llvm-svn: 322043
* Update docs version and clear release notes for 7.0.0Hans Wennborg2018-01-031-170/+14
| | | | llvm-svn: 321728
* [docs] Updated ReleaseNotes for OpenMP part.Alexey Bataev2017-12-291-1/+12
| | | | llvm-svn: 321561
* Harmonize GNU- and C++-style attribute spellings.Aaron Ballman2017-12-141-0/+6
| | | | | | | | Most attributes will now use the Clang<"name"> construct to provide both __attribute__((name)) and [[clang::name]] syntaxes for the attribute. Attributes deviating from this should be marked with a comment explaining why they are not supported under both spellings. Common reasons are: the attribute is provided by some other specification that controls the syntax or the attribute cannot be exposed under a particular spelling for some given reason. Because this is a mechanical change that only introduces new spellings, there are no test cases for the commit. llvm-svn: 320752
* [Preprocessor] Implement __is_target_{arch|vendor|os|environment} function-likeAlex Lorenz2017-12-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | builtin macros This patch implements the __is_target_arch, __is_target_vendor, __is_target_os, and __is_target_environment Clang preprocessor extensions that were proposed by @compnerd in Bob's cfe-dev post: http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html. These macros can be used to examine the components of the target triple at compile time. A has_builtin(is_target_???) preprocessor check can be used to check for their availability. __is_target_arch allows you to check if an arch is specified without worring about a specific subarch, e.g. __is_target_arch(arm) returns 1 for the target arch "armv7" __is_target_arch(armv7) returns 1 for the target arch "armv7" __is_target_arch(armv6) returns 0 for the target arch "armv7" __is_target_vendor and __is_target_environment match the specific vendor or environment. __is_target_os matches the specific OS, but __is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be used to test if the triple's component is specified. rdar://35753116 Differential Revision: https://reviews.llvm.org/D41087 llvm-svn: 320734
* Switch to gnu++14 as the default dialect.Tim Northover2017-12-091-1/+4
| | | | | | This is C++14 with conforming GNU extensions. llvm-svn: 320250
* Add new language mode flags for C17.Aaron Ballman2017-12-071-0/+6
| | | | | | This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes. llvm-svn: 320089
* Add support for the __has_c_attribute builtin preprocessor macro.Aaron Ballman2017-12-071-0/+5
| | | | | | This behaves similar to the __has_cpp_attribute builtin macro in that it allows users to detect whether an attribute is supported with the [[]] spelling syntax, which can be enabled in C with -fdouble-square-bracket-attributes. llvm-svn: 320088
* [clang-format] Releasenotes for rL319024 : Add option to group multiple ↵Sylvestre Ledru2017-12-051-0/+13
| | | | | | | | | | | | | | | | | | #include blocks when sorting includes Summary: This change adds missing releasenotes for commit rL319024 https://reviews.llvm.org/rL319024 Patch by Krzysztof Kapusta Reviewers: sylvestre.ledru Reviewed By: sylvestre.ledru Differential Revision: https://reviews.llvm.org/D40827 llvm-svn: 319748
* [analyzer] Fix false negative on post-increment of uninitialized variable.Roman Lebedev2017-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang static analyzer does warn on: ``` int x; x+=1; x-=1; x=x+1; x=x-1; ``` But does warn on: ``` int x; x++; x--; --x; ++x; ``` This differential should fix that. Fixes https://bugs.llvm.org/show_bug.cgi?id=35419 Reviewers: dcoughlin, NoQ Reviewed By: dcoughlin Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin Tags: #clang Differential Revision: https://reviews.llvm.org/D40463 llvm-svn: 319411
* [Sema] Document+test the -Wsign-conversion change for enums in C code [NFC]Roman Lebedev2017-11-041-1/+2
| | | | | | | | | | | | Basically a regression after r316268. However the diagnostic is correct, but the test coverage is bad. So just like rL316500, introduce yet more tests, and adjust the release notes. See https://bugs.llvm.org/show_bug.cgi?id=35200 llvm-svn: 317421
* Use -fuse-init-array if no gcc installation is found.Nico Weber2017-10-261-0/+4
| | | | | | | | | | | | | | | | clang currently uses .init_array instead of .ctors on Linux if it detects gcc 4.7+. Make it so that it also uses .init_array if no gcc installation is found at all – if there's no old gcc, there's nothing we need to be compatible with. icecc for example runs clang in a very small chroot, so before this change clang would use .ctors if run under icecc. And lld currently silently mislinks inputs with .ctors sections, so before this clang + icecc + lld would produce broken binaries. (But this seems like a good change independent of that lld bug.) https://reviews.llvm.org/D39317 llvm-svn: 316713
* [Sema] -Wzero-as-null-pointer-constant: don't warn for system macros other ↵Roman Lebedev2017-10-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | than NULL. Summary: The warning was initially introduced in D32914 by @thakis, and the concerns were raised there, and later in rL302247 and PR33771. I do believe that it makes sense to relax the diagnostic e.g. in this case, when the expression originates from the system header, which can not be modified. This prevents adoption for the diagnostic for codebases which use pthreads (`PTHREAD_MUTEX_INITIALIZER`), gtest, etc. As @malcolm.parsons suggests, it *may* make sense to also not warn for the template types, but it is not obvious to me how to do that in here. Though, it still makes sense to complain about `NULL` macro. While there, add more tests. Reviewers: dblaikie, thakis, rsmith, rjmccall, aaron.ballman Reviewed By: thakis Subscribers: Rakete1111, hans, cfe-commits, thakis, malcolm.parsons Tags: #clang Differential Revision: https://reviews.llvm.org/D38954 llvm-svn: 316662
* [Sema] Document+test the -Wsign-compare change for enums in C code [NFC]Roman Lebedev2017-10-241-0/+4
| | | | | | | | | | | | | | | | | | rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
* Add release notes for the recent -fdouble-square-bracket-attributes and ↵Aaron Ballman2017-10-211-0/+7
| | | | | | -fno-double-square-bracket-attributes compiler flags. llvm-svn: 316269
* [Sema] Re-land: Diagnose tautological comparison with type's min/max valuesRoman Lebedev2017-10-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The first attempt, rL315614 was reverted because one libcxx test broke, and i did not know at the time how to deal with it. Summary: Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`), and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the `std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147 Continuation of https://reviews.llvm.org/D37565 Reviewers: rjmccall, rsmith, aaron.ballman Reviewed By: rsmith Subscribers: rtrieu, jroelofs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38101 llvm-svn: 315875
OpenPOWER on IntegriCloud