summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* [Sema] Deduplicate some availability checking logicErik Pilkington2019-03-202-17/+16
| | | | | | | | | | | | | | | Before this commit, we emit unavailable errors for calls to functions during overload resolution, and for references to all other declarations in DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as the DiagnoseAvailabilityOfDecl based checks, as they error on the code from PR40991. This commit fixes this by removing the early checking. llvm.org/PR40991 rdar://48564179 Differential revision: https://reviews.llvm.org/D59394 llvm-svn: 356599
* Add a spelling of pass_object_size that uses __builtin_dynamic_object_sizeErik Pilkington2019-03-191-5/+17
| | | | | | | | | | | The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
* Ensure that const variables declared at namespace scope correctly have ↵Aaron Ballman2019-03-192-0/+59
| | | | | | | | external linkage when marked as dllexport and targeting the MSVC ABI. Patch thanks to Zahira Ammarguellat. llvm-svn: 356458
* Thread safety analysis: Add note for unlock kind mismatchAaron Puchert2019-03-181-2/+2
| | | | | | | | | | | | | | | | | | Summary: Similar to D56967, we add the existing diag::note_locked_here to tell the user where we saw the locking that isn't matched correctly. Reviewers: aaron.ballman, delesley Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59455 llvm-svn: 356427
* [Sema] Add some compile time _FORTIFY_SOURCE diagnosticsErik Pilkington2019-03-185-9/+92
| | | | | | | | | | | | | | | | | | | | | | | These diagnose overflowing calls to subset of fortifiable functions. Some functions, like sprintf or strcpy aren't supported right not, but we should probably support these in the future. We previously supported this kind of functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work with _FORTIFY implementations that use wrapper functions. Also unlike that diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is actually enabled, which is nice for programs that don't enable the runtime checks. Why not just use diagnose_if, like Bionic does? We can get better diagnostics in the compiler (i.e. mention the sizes), and we have the potential to diagnose sprintf and strcpy which is impossible with diagnose_if (at least, in languages that don't support C++14 constexpr). This approach also saves standard libraries from having to add diagnose_if. rdar://48006655 Differential revision: https://reviews.llvm.org/D58797 llvm-svn: 356397
* Reland the rest of "Add AIX Target Info"Jason Liu2019-03-141-0/+6
| | | | | | | | | llvm-svn 356197 relanded previously failing test case max_align.c. This commit will reland the rest of llvm-svn 356060 commit. Differential Revision: https://reviews.llvm.org/D59048 llvm-svn: 356208
* Revert "Add a new attribute, fortify_stdlib"Erik Pilkington2019-03-131-18/+0
| | | | | | | | | | This reverts commit r353765. After talking with our c stdlib folks, we decided to use the existing pass_object_size attribute to implement _FORTIFY_SOURCE wrappers, like Bionic does (I didn't realize that pass_object_size could be used for this purpose). Sorry for the flip/flop, and thanks to James Y. Knight for pointing this out to me. llvm-svn: 356103
* Revert "Add AIX Target Info"Jason Liu2019-03-131-6/+0
| | | | | | | | | This reverts commit 4e192d0e1e72ce32fabf1bccc06ac31ab5385e78. The newly added test case max_align.c do not work on all platforms. original llvm-svn: 356060 llvm-svn: 356070
* Add AIX Target InfoJason Liu2019-03-131-0/+6
| | | | | | | | | | | | | | | | | | Summary: A first pass over platform-specific properties of the C API/ABI on AIX for both 32-bit and 64-bit modes. This is a continuation of D18360 by Andrew Paprocki and further work by Wu Zhao. Patch by Andus Yu Reviewers: apaprocki, chandlerc, hubert.reinterpretcast, jasonliu, xingxue, sfertile Reviewed by: hubert.reinterpretcast, apaprocki, sfertile Differential Revision: https://reviews.llvm.org/D59048 llvm-svn: 356060
* Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)Hans Wennborg2019-03-061-1/+19
| | | | | | | | | | | | Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 llvm-svn: 355491
* Ensure that set constrained asm operands are not affected by truncation.Joerg Sonnenberger2019-02-281-0/+4
| | | | llvm-svn: 355058
* Fix inline assembler constraint validationJoerg Sonnenberger2019-02-271-0/+4
| | | | | | | | | | | The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly. Differential Revision: https://reviews.llvm.org/D58649 llvm-svn: 354937
* [OPENMP][CUDA]Do not emit warnings for variables in late-reported asmAlexey Bataev2019-02-261-1/+1
| | | | | | | | | | | | statements. If the assembler instruction is not generated and the delayed diagnostic is emitted, we may end up with extra warning message for variables used in the asm statement. Since the asm statement is not built, the variables may be left non-referenced and it may produce a warning about a use of the non-initialized variables. llvm-svn: 354928
* [attributes] Add an attribute for server routines in Mach kernel and extensions.Artem Dergachev2019-02-213-0/+73
| | | | | | | | | | | | The new __attribute__ ((mig_server_routine)) is going to be used for annotating Mach Interface Generator (MIG) callback functions as such, so that additional static analysis could be applied to their implementations. It can also be applied to regular functions behavior of which is supposed to be identical to that of a MIG server routine. Differential Revision: https://reviews.llvm.org/D58365 llvm-svn: 354530
* Fix some tests I broke in r354190Erik Pilkington2019-02-161-1/+1
| | | | | | | This was breaking on MSVC, since long double and double have the same semantics there. llvm-svn: 354192
* [Sema] Diagnose floating point conversions based on target semanticsErik Pilkington2019-02-161-0/+24
| | | | | | | | | | ...instead of just comparing rank. Also, fix a bad warning about _Float16, since its declared out of order in BuiltinTypes.def, meaning comparing rank using BuiltinType::getKind() is incorrect. Differential revision: https://reviews.llvm.org/D58254 llvm-svn: 354190
* [Sema] Fix a regression introduced in "[AST][Sema] Remove CallExpr::setNumArgs"Bruno Ricci2019-02-141-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | D54902 removed CallExpr::setNumArgs in preparation of tail-allocating the arguments of CallExpr. It did this by allocating storage for max(number of arguments, number of parameters in the prototype). The temporarily nulled arguments however causes issues in BuildResolvedCallExpr when typo correction is done just after the creation of the call expression. This was unfortunately missed by the tests /: To fix this, delay setting the number of arguments to max(number of arguments, number of parameters in the prototype) until we are ready for it. It would be nice to have this encapsulated in CallExpr but this is the best I can come up with under the constraint that we cannot add anything the CallExpr. Fixes PR40286. Differential Revision: https://reviews.llvm.org/D57948 Reviewed By: aaron.ballman llvm-svn: 354035
* [Headers][mips] Add `__attribute__((__mode__(__unwind_word__)))` to the ↵Simon Atanasyan2019-02-131-1/+16
| | | | | | | | | | | | | | | | | | _Unwind_Word / _Unwind_SWord definitions The rationale of this change is to fix _Unwind_Word / _Unwind_SWord definitions for MIPS N32 ABI. This ABI uses 32-bit pointers, but _Unwind_Word and _Unwind_SWord types are eight bytes long. # The __attribute__((__mode__(__unwind_word__))) is added to the type definitions. It makes them equal to the corresponding definitions used by GCC and allows to override types using `getUnwindWordWidth` function. # The `getUnwindWordWidth` virtual function override in the `MipsTargetInfo` class and provides correct type size values. Differential revision: https://reviews.llvm.org/D58165 llvm-svn: 353965
* [Sema] Fix a crash in access checking for deduction guidesIlya Biryukov2019-02-121-0/+11
| | | | | | | | | | | | | | | | Summary: See the added test for a repro. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58111 llvm-svn: 353840
* Add a new attribute, fortify_stdlibErik Pilkington2019-02-111-0/+18
| | | | | | | | | | | | | | | | | | | | | | This attribute applies to declarations of C stdlib functions (sprintf, memcpy...) that have known fortified variants (__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit calls to the fortified variant functions instead of calls to the defaults. In GCC, this is done by adding gnu_inline-style wrapper functions, but that doesn't work for us for variadic functions because we don't support __builtin_va_arg_pack (and have no intention to). This attribute takes two arguments, the first is 'type' argument passed through to __builtin_object_size, and the second is a flag argument that gets passed through to the variadic checking variants. rdar://47905754 Differential revision: https://reviews.llvm.org/D57918 llvm-svn: 353765
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-20/+27
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* Fix thread safety tests after r352549Aaron Puchert2019-01-301-1/+1
| | | | llvm-svn: 352574
* OpenCL: Use length modifier for warning on vector printf argumentsMatt Arsenault2019-01-291-0/+2
| | | | | | | | | | | | Re-enable format string warnings on printf. The warnings are still incomplete. Apparently it is undefined to use a vector specifier without a length modifier, which is not currently warned on. Additionally, type warnings appear to not be working with the hh modifier, and aren't warning on all of the special restrictions from c99 printf. llvm-svn: 352540
* [Sema] Improve a -Warray-bounds diagnosticErik Pilkington2019-01-251-2/+10
| | | | | | | | | | | Fix a bug where we would compare array sizes with incompatible element types, and look through explicit casts. rdar://44800168 Differential revision: https://reviews.llvm.org/D57064 llvm-svn: 352239
* Disable _Float16 for non ARM/SPIR TargetsErich Keane2019-01-251-0/+11
| | | | | | | | | | | | | | As Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html There are problems exposing the _Float16 type on architectures that haven't defined the ABI/ISel for the type yet, so we're temporarily disabling the type and making it opt-in. Differential Revision: https://reviews.llvm.org/D57188 Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736 llvm-svn: 352221
* [CPU-Dispatch] Make pentium_iii_no_xmm_regs and pentium_iii alias.Erich Keane2019-01-241-0/+3
| | | | | | | | | | | | | | | | I discovered that in ICC (where this list comes from), that the two pentium_iii versions were actually identical despite the two different names (despite them implying a difference). Because of this, they ended up having identical manglings, which obviously caused problems when used together. This patch makes pentium_iii_no_xmm_regs an alias for pentium_iii so that it can still be used, but has the same meaning as ICC. However, we still prohibit using the two together which is different (albeit better) behavior. Change-Id: I4f3c9a47e48490c81525c8a3d23ed4201921b288 llvm-svn: 352054
* Emit !callback metadata and introduce the callback attributeJohannes Doerfert2019-01-192-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | With commit r351627, LLVM gained the ability to apply (existing) IPO optimizations on indirections through callbacks, or transitive calls. The general idea is that we use an abstraction to hide the middle man and represent the callback call in the context of the initial caller. It is described in more detail in the commit message of the LLVM patch r351627, the llvm::AbstractCallSite class description, and the language reference section on callback-metadata. This commit enables clang to emit !callback metadata that is understood by LLVM. It does so in three different cases: 1) For known broker functions declarations that are directly generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel. 2) For known broker functions that are identified by their name and source location through the builtin detection, e.g., pthread_create from the POSIX thread API. 3) For user annotated functions that carry the "callback(callee, ...)" attribute. The attribute has to include the name, or index, of the callback callee and how the passed arguments can be identified (as many as the callback callee has). See the callback attribute documentation for detailed information. Differential Revision: https://reviews.llvm.org/D55483 llvm-svn: 351629
* [Sema] Suppress a warning about a forward-declared fixed enum in C modeErik Pilkington2019-01-181-1/+22
| | | | | | | | | | | | | | | As of r343360, we support fixed-enums in C. This lead to some warnings in project headers where a fixed enum is forward declared then later defined. In C++, this is fine, the forward declaration is treated as a complete type even though the definition isn't present. We use this rule in C too, but still warn about the forward declaration anyways. This patch suppresses the warning. rdar://problem/47356469 Differential revision: https://reviews.llvm.org/D56879 llvm-svn: 351595
* [MSP430] Improve support of 'interrupt' attributeAnton Korobeynikov2019-01-161-2/+9
| | | | | | | | | | | | * Accept as an argument constants in range 0..63 (aligned with TI headers and linker scripts provided with TI GCC toolchain). * Emit function attribute 'interrupt'='xx' instead of aliases (used in the backend to create a section for particular interrupt vector). * Add more diagnostics. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56663 llvm-svn: 351344
* Fix cpu-dispatch MV regression caused by r347812Erich Keane2019-01-151-0/+8
| | | | | | | | | | | r347812 permitted forward declarations for cpu-dispatch functions, which are occassionally useful as exposition in header files. However, this inadvertently permitted this function to become multiversioned after a usage. This patch ensures that the "CausesMV" checks are still run in the forward-declaration case. Change-Id: Icb6f975a2d068f088b89e3bbe26cf1d24f5a972c llvm-svn: 351212
* Improve a -Wunguarded-availability noteErik Pilkington2019-01-142-5/+5
| | | | | | | | | | | Mention the deployment target, and don't say "partial" which doesn't really mean anything to users. rdar://problem/33601513 Differential revision: https://reviews.llvm.org/D56523 llvm-svn: 351108
* [Sema] Expose a control flag for integer to pointer ext warningKristina Brooks2019-01-141-0/+12
| | | | | | | | | | | | | While building openJDK11u, it seems that some of the code in the native core libraries make liberal use of integer to pointer comparisons. We currently have no flag to disabled this warning. This add such a flag. Patch by Kader (abdoul-kader keita) Differential Revision: https://reviews.llvm.org/D56241 llvm-svn: 351082
* [attributes] Extend os_returns_(not_?)_retained attributes to parametersGeorge Karpenkov2019-01-112-4/+30
| | | | | | | | | | | When applied to out-parameters, the attributes specify the expected lifetime of the written-into object. Additionally, introduce OSReturnsRetainedOn(Non)Zero attributes, which specify that an ownership transfer happens depending on a return code. Differential Revision: https://reviews.llvm.org/D56292 llvm-svn: 350942
* [Sema] Mark target of __attribute__((alias("target"))) used for CNick Desaulniers2019-01-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Prevents -Wunneeded-internal-delcaration warnings when the target has no other references. This occurs frequently in device drivers in the Linux kernel. Sema would need to invoke the demangler on the target, since in C++ the target name is mangled: int f() { return 42; } int g() __attribute__((alias("_Z1fv"))); Sema does not have the ability to demangle names at this time. https://bugs.llvm.org/show_bug.cgi?id=39088 https://github.com/ClangBuiltLinux/linux/issues/232 Reviewers: rsmith, rjmccall Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits, pirama, srhines Differential Revision: https://reviews.llvm.org/D54188 llvm-svn: 350776
* __has_feature(pragma_clang_attribute_namespaces) should be __has_extensionErik Pilkington2019-01-081-1/+1
| | | | | | Thanks to Richard Smith for pointing this out. llvm-svn: 350642
* Add a __has_feature check for namespaces on #pragma clang attribute.Erik Pilkington2019-01-071-0/+4
| | | | | | Support for this was added in r349845. llvm-svn: 350572
* Add two new pragmas for controlling software pipelining optimizations.Aaron Ballman2019-01-041-0/+34
| | | | | | | | This patch adds #pragma clang loop pipeline and #pragma clang loop pipeline_initiation_interval for debugging or reducing compile time purposes. It is possible to disable SWP for concrete loops to save compilation time or to find bugs by not doing SWP to certain loops. It is possible to set value of initiation interval to concrete number to save compilation time by not doing extra pipeliner passes or to check created schedule for specific initiation interval. Patch by Alexey Lapshin. llvm-svn: 350414
* Prevent unreachable when checking invalid multiversion decls.Erich Keane2019-01-041-0/+12
| | | | | | | | | | | CPUSpecifc/CPUDispatch call resolution assumed that all declarations that would be passed are valid, however this was an invalid assumption. This patch deals with those situations by making the valid version take priority. Note that the checked ordering is arbitrary, since both are replaced by calls to the resolver later. Change-Id: I7ff2ec88c55a721d51bc1f39ea1a1fe242b4e45f llvm-svn: 350398
* Add support for namespaces on #pragma clang attributeErik Pilkington2018-12-201-0/+37
| | | | | | | | | | | | | | | | Namespaces are introduced by adding an "identifier." before a push/pop directive. Pop directives with namespaces can only pop a attribute group that was pushed with the same namespace. Push and pop directives that don't opt into namespaces have the same semantics. This is necessary to prevent a pitfall of using multiple #pragma clang attribute directives spread out in a large file, particularly when macros are involved. It isn't easy to see which pop corripsonds to which push, so its easy to inadvertently pop the wrong group. Differential revision: https://reviews.llvm.org/D55628 llvm-svn: 349845
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-182-0/+39
| | | | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. Patch by Bevin Hansson. llvm-svn: 349497
* Automatic variable initializationJF Bastien2018-12-182-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive. This isn't meant to change the semantics of C and C++. Rather, it's meant to be a last-resort when programmers inadvertently have some undefined behavior in their code. This patch aims to make undefined behavior hurt less, which security-minded people will be very happy about. Notably, this means that there's no inadvertent information leak when: - The compiler re-uses stack slots, and a value is used uninitialized. - The compiler re-uses a register, and a value is used uninitialized. - Stack structs / arrays / unions with padding are copied. This patch only addresses stack and register information leaks. There's many more infoleaks that we could address, and much more undefined behavior that could be tamed. Let's keep this patch focused, and I'm happy to address related issues elsewhere. To keep the patch simple, only some `undef` is removed for now, see `replaceUndef`. The padding-related infoleaks are therefore not all gone yet. This will be addressed in a follow-up, mainly because addressing padding-related leaks should be a stand-alone option which is implied by variable initialization. There are three options when it comes to automatic variable initialization: 0. Uninitialized This is C and C++'s default. It's not changing. Depending on code generation, a programmer who runs into undefined behavior by using an uninialized automatic variable may observe any previous value (including program secrets), or any value which the compiler saw fit to materialize on the stack or in a register (this could be to synthesize an immediate, to refer to code or data locations, to generate cookies, etc). 1. Pattern initialization This is the recommended initialization approach. Pattern initialization's goal is to initialize automatic variables with values which will likely transform logic bugs into crashes down the line, are easily recognizable in a crash dump, without being values which programmers can rely on for useful program semantics. At the same time, pattern initialization tries to generate code which will optimize well. You'll find the following details in `patternFor`: - Integers are initialized with repeated 0xAA bytes (infinite scream). - Vectors of integers are also initialized with infinite scream. - Pointers are initialized with infinite scream on 64-bit platforms because it's an unmappable pointer value on architectures I'm aware of. Pointers are initialize to 0x000000AA (small scream) on 32-bit platforms because 32-bit platforms don't consistently offer unmappable pages. When they do it's usually the zero page. As people try this out, I expect that we'll want to allow different platforms to customize this, let's do so later. - Vectors of pointers are initialized the same way pointers are. - Floating point values and vectors are initialized with a negative quiet NaN with repeated 0xFF payload (e.g. 0xffffffff and 0xffffffffffffffff). NaNs are nice (here, anways) because they propagate on arithmetic, making it more likely that entire computations become NaN when a single uninitialized value sneaks in. - Arrays are initialized to their homogeneous elements' initialization value, repeated. Stack-based Variable-Length Arrays (VLAs) are runtime-initialized to the allocated size (no effort is made for negative size, but zero-sized VLAs are untouched even if technically undefined). - Structs are initialized to their heterogeneous element's initialization values. Zero-size structs are initialized as 0xAA since they're allocated a single byte. - Unions are initialized using the initialization for the largest member of the union. Expect the values used for pattern initialization to change over time, as we refine heuristics (both for performance and security). The goal is truly to avoid injecting semantics into undefined behavior, and we should be comfortable changing these values when there's a worthwhile point in doing so. Why so much infinite scream? Repeated byte patterns tend to be easy to synthesize on most architectures, and otherwise memset is usually very efficient. For values which aren't entirely repeated byte patterns, LLVM will often generate code which does memset + a few stores. 2. Zero initialization Zero initialize all values. This has the unfortunate side-effect of providing semantics to otherwise undefined behavior, programs therefore might start to rely on this behavior, and that's sad. However, some programmers believe that pattern initialization is too expensive for them, and data might show that they're right. The only way to make these programmers wrong is to offer zero-initialization as an option, figure out where they are right, and optimize the compiler into submission. Until the compiler provides acceptable performance for all security-minded code, zero initialization is a useful (if blunt) tool. I've been asked for a fourth initialization option: user-provided byte value. This might be useful, and can easily be added later. Why is an out-of band initialization mecanism desired? We could instead use -Wuninitialized! Indeed we could, but then we're forcing the programmer to provide semantics for something which doesn't actually have any (it's uninitialized!). It's then unclear whether `int derp = 0;` lends meaning to `0`, or whether it's just there to shut that warning up. It's also way easier to use a compiler flag than it is to manually and intelligently initialize all values in a program. Why not just rely on static analysis? Because it cannot reason about all dynamic code paths effectively, and it has false positives. It's a great tool, could get even better, but it's simply incapable of catching all uses of uninitialized values. Why not just rely on memory sanitizer? Because it's not universally available, has a 3x performance cost, and shouldn't be deployed in production. Again, it's a great tool, it'll find the dynamic uses of uninitialized variables that your test coverage hits, but it won't find the ones that you encounter in production. What's the performance like? Not too bad! Previous publications [0] have cited 2.7 to 4.5% averages. We've commmitted a few patches over the last few months to address specific regressions, both in code size and performance. In all cases, the optimizations are generally useful, but variable initialization benefits from them a lot more than regular code does. We've got a handful of other optimizations in mind, but the code is in good enough shape and has found enough latent issues that it's a good time to get the change reviewed, checked in, and have others kick the tires. We'll continue reducing overheads as we try this out on diverse codebases. Is it a good idea? Security-minded folks think so, and apparently so does the Microsoft Visual Studio team [1] who say "Between 2017 and mid 2018, this feature would have killed 49 MSRC cases that involved uninitialized struct data leaking across a trust boundary. It would have also mitigated a number of bugs involving uninitialized struct data being used directly.". They seem to use pure zero initialization, and claim to have taken the overheads down to within noise. Don't just trust Microsoft though, here's another relevant person asking for this [2]. It's been proposed for GCC [3] and LLVM [4] before. What are the caveats? A few! - Variables declared in unreachable code, and used later, aren't initialized. This goto, Duff's device, other objectionable uses of switch. This should instead be a hard-error in any serious codebase. - Volatile stack variables are still weird. That's pre-existing, it's really the language's fault and this patch keeps it weird. We should deprecate volatile [5]. - As noted above, padding isn't fully handled yet. I don't think these caveats make the patch untenable because they can be addressed separately. Should this be on by default? Maybe, in some circumstances. It's a conversation we can have when we've tried it out sufficiently, and we're confident that we've eliminated enough of the overheads that most codebases would want to opt-in. Let's keep our precious undefined behavior until that point in time. How do I use it: 1. On the command-line: -ftrivial-auto-var-init=uninitialized (the default) -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 2. Using an attribute: int dont_initialize_me __attribute((uninitialized)); [0]: https://users.elis.ugent.be/~jsartor/researchDocs/OOPSLA2011Zero-submit.pdf [1]: https://twitter.com/JosephBialek/status/1062774315098112001 [2]: https://outflux.net/slides/2018/lss/danger.pdf [3]: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html [4]: https://github.com/AndroidHardeningArchive/platform_external_clang/commit/776a0955ef6686d23a82d2e6a3cbd4a6a882c31c [5]: http://wg21.link/p1152 I've also posted an RFC to cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html <rdar://problem/39131435> Reviewers: pcc, kcc, rsmith Subscribers: JDevlieghere, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54604 llvm-svn: 349442
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+18
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* Replace Const-Member checking with non-recursive version.Erich Keane2018-12-111-0/+34
| | | | | | | | | | | | | | As reported in PR39946, these two implementations cause stack overflows to occur when a type recursively contains itself. While this only happens when an incomplete version of itself is used by membership (and thus an otherwise invalid program), the crashes might be surprising. The solution here is to replace the recursive implementation with one that uses a std::vector as a queue. Old values are kept around to prevent re-checking already checked types. Change-Id: I582bb27147104763d7daefcfee39d91f408b9fa8 llvm-svn: 348899
* Revert r348889; it fails some tests.Aaron Ballman2018-12-112-39/+0
| | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/40784 llvm-svn: 348892
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-112-0/+39
| | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. llvm-svn: 348889
* Reland r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-111-1/+1
| | | | | | Fix a dangling reference to temporary, never return nullptr. llvm-svn: 348834
* Revert r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-101-1/+1
| | | | | | Seems to break build bots. llvm-svn: 348742
* [Sema] Further improvements to to static_assert diagnostics.Clement Courbet2018-12-101-1/+1
| | | | | | | | | | | | | | Summary: We're now handling cases like `static_assert(!expr)` and static_assert(!(expr))`. Reviewers: aaron.ballman, Quuxplusone Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55270 llvm-svn: 348741
* [attributes] Add an attribute os_consumes_this, with similar semantics to ↵George Karpenkov2018-12-061-1/+7
| | | | | | | | | | | ns_consumes_self The attribute specifies that the call of the C++ method consumes a reference to "this". Differential Revision: https://reviews.llvm.org/D55155 llvm-svn: 348532
* ARM, AArch64: support `__attribute__((__swiftcall__))`Saleem Abdulrasool2018-12-061-0/+7
| | | | | | | | | | Support the Swift calling convention on Windows ARM and AArch64. Both of these conform to the AAPCS, AAPCS64 calling convention, and LLVM has been adjusted to account for the register usage. Ensure that the frontend passes this into the backend. This allows the swift runtime to be built for Windows. llvm-svn: 348454
OpenPOWER on IntegriCloud