summaryrefslogtreecommitdiffstats
path: root/lib/Frontend/CompilerInvocation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Don't display implementation checkers under ↵Kristof Umann2019-05-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden During my work on analyzer dependencies, I created a great amount of new checkers that emitted no diagnostics at all, and were purely modeling some function or another. However, the user shouldn't really disable/enable these by hand, hence this patch, which hides these by default. I intentionally chose not to hide alpha checkers, because they have a scary enough name, in my opinion, to cause no surprise when they emit false positives or cause crashes. The patch introduces the Hidden bit into the TableGen files (you may remember it before I removed it in D53995), and checkers that are either marked as hidden, or are in a package that is marked hidden won't be displayed under -analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for developers only, displays the full list. Differential Revision: https://reviews.llvm.org/D60925 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359720 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer][NFC] Reimplement checker optionsKristof Umann2019-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: * Add checker and package options to the TableGen files * Added a new class called CmdLineOption, and both Package and Checker recieved a list<CmdLineOption> field. * Added every existing checker and package option to Checkers.td. * The CheckerRegistry class * Received some comments to most of it's inline classes * Received the CmdLineOption and PackageInfo inline classes, a list of CmdLineOption was added to CheckerInfo and PackageInfo * Added addCheckerOption and addPackageOption * Added a new field called Packages, used in addPackageOptions, filled up in addPackage Detailed description: In the last couple months, a lot of effort was put into tightening the analyzer's command line interface. The main issue is that it's spectacularly easy to mess up a lenghty enough invocation of the analyzer, and the user was given no warnings or errors at all in that case. We can divide the effort of resolving this into several chapters: * Non-checker analyzer configurations: Gather every analyzer configuration into a dedicated file. Emit errors for non-existent configurations or incorrect values. Be able to list these configurations. Tighten AnalyzerOptions interface to disallow making such a mistake in the future. * Fix the "Checker Naming Bug" by reimplementing checker dependencies: When cplusplus.InnerPointer was enabled, it implicitly registered unix.Malloc, which implicitly registered some sort of a modeling checker from the CStringChecker family. This resulted in all of these checker objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions asking for the wrong checker options from the command line: cplusplus.InnerPointer:Optimisic istead of unix.Malloc:Optimistic. This was resolved by making CheckerRegistry responsible for checker dependency handling, instead of checkers themselves. * Checker options: (this patch included!) Same as the first item, but for checkers. (+ minor fixes here and there, and everything else that is yet to come) There were several issues regarding checker options, that non-checker configurations didn't suffer from: checker plugins are loaded runtime, and they could add new checkers and new options, meaning that unlike for non-checker configurations, we can't collect every checker option purely by generating code. Also, as seen from the "Checker Naming Bug" issue raised above, they are very rarely used in practice, and all sorts of skeletons fell out of the closet while working on this project. They were extremely problematic for users as well, purely because of how long they were. Consider the following monster of a checker option: alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false While we were able to verify whether the checker itself (the part before the colon) existed, any errors past that point were unreported, easily resulting in 7+ hours of analyses going to waste. This patch, similarly to how dependencies were reimplemented, uses TableGen to register checker options into Checkers.td, so that Checkers.inc now contains entries for both checker and package options. Using the preprocessor, Checkers.inc is converted into code in CheckerRegistry, adding every builtin (checkers and packages that have an entry in the Checkers.td file) checker and package option to the registry. The new addPackageOption and addCheckerOption functions expose the same functionality to statically-linked non-builtin and plugin checkers and packages as well. Emitting errors for incorrect user input, being able to list these options, and some other functionalies will land in later patches. Differential Revision: https://reviews.llvm.org/D57855 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@358752 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-111-2/+7
| | | | | | in the preprocessor. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@358231 91177308-0d34-0410-b5e6-96231b3b80d8
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-311-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357359 91177308-0d34-0410-b5e6-96231b3b80d8
* Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` ↵Anton Afanasyev2019-03-301-0/+1
| | | | | | | | | | | | | | compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357340 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355984 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-5/+0
| | | | | | This reverts commit 20fff32b7d1f1a1bd417b22aa9f26ededd97a3e5. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355976 91177308-0d34-0410-b5e6-96231b3b80d8
* [Remarks] Add -foptimization-record-passes to filter remark emissionFrancis Visoiu Mistrih2019-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355964 91177308-0d34-0410-b5e6-96231b3b80d8
* [PGO] Clang part of change for context-sensitive PGO (part1)Rong Xu2019-03-041-3/+7
| | | | | | | | | | | | Part 1 of CSPGO change in Clang. This includes changes in clang options and calls to llvm PassManager. Tests will be committed in part2. This change needs the PassManager change in llvm. Differential Revision: https://reviews.llvm.org/D54176 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355331 91177308-0d34-0410-b5e6-96231b3b80d8
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-03-011-1/+1
| | | | | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". This is a recommit of r354873 but with a fix for unqualified lookup error in lldb cmake build bot. Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355190 91177308-0d34-0410-b5e6-96231b3b80d8
* revert r354873 as this breaks lldb builds.Pierre Gousseau2019-02-261-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354875 91177308-0d34-0410-b5e6-96231b3b80d8
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-02-261-1/+1
| | | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354873 91177308-0d34-0410-b5e6-96231b3b80d8
* [SYCL] Add clang front-end option to enable SYCL device compilation flow.Alexey Bader2019-02-251-0/+2
| | | | | | Patch by Mariya Podchishchaeva <[email protected]> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354773 91177308-0d34-0410-b5e6-96231b3b80d8
* Enable coroutines under -std=c++2a.Richard Smith2019-02-231-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354736 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP][NVPTX]Use faster teams reduction algorithm.Alexey Bataev2019-02-201-0/+3
| | | | | | | A faster way to reduce the values in teams reductions was found, the codegen is updated to use this faster algorithm and new runtime functions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354479 91177308-0d34-0410-b5e6-96231b3b80d8
* [ARM] Add pre-defined macros for ROPI and RWPIOliver Stannard2019-02-181-0/+2
| | | | | | | | | | | This adds ACLE-defined macros to test for code being compiled in the ROPI and RWPI position-independence modes. Differential revision: https://reviews.llvm.org/D23610 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@354265 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Delay emission of the error messages for the exceptions.Alexey Bataev2019-02-081-1/+0
| | | | | | | | | | Fixed diagnostic emission for the exceptions support in case of the compilation of OpenMP code for the devices. From now on, it uses delayed diagnostics mechanism, previously used for CUDA only. It allow to diagnose not allowed used of exceptions only in functions that are going to be codegen'ed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@353542 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[OPENMP]Initial support for the delayed diagnostics."Alexey Bataev2019-02-081-0/+1
| | | | | | | This reverts commit r353540. Erroneously committed, need to fix the message and description. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@353541 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Initial support for the delayed diagnostics.Alexey Bataev2019-02-081-1/+0
| | | | | | | | | It is important to delay the emission of the diagnostic messages for the functions unless it is proved that the function is going to be used on the device side. It is required to support compilation with some of the target-specific system headers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@353540 91177308-0d34-0410-b5e6-96231b3b80d8
* [NewPM] Add support for new-PM plugins to clangPhilip Pfaffe2019-02-021-0/+2
| | | | | | | | | | | | | | | Summary: This adds support for new-PM plugin loading to clang. The option `-fpass-plugin=` may be used to specify a dynamic shared object file that adheres to the PassPlugin API. Tested: created simple plugin that registers an EP callback; with optimization level > 0, the pass is run as expected. Committed on behalf of Marco Elver Differential Revision: https://reviews.llvm.org/D56935 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@352972 91177308-0d34-0410-b5e6-96231b3b80d8
* Make clang/test/Index/pch-from-libclang.c pass in more placesNico Weber2019-01-311-12/+2
| | | | | | | | | | | | | | | | - fixes the test on macOS with LLVM_ENABLE_PIC=OFF - together with D57343, gets the test to pass on Windows - makes it run everywhere (it seems to just pass on Linux) The main change is to pull out the resource directory computation into a function shared by all 3 places that do it. In CIndexer.cpp, this now works no matter if libclang is in lib/ or bin/ or statically linked to a binary in bin/. Differential Revision: https://reviews.llvm.org/D57345 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@352803 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -fapply-global-visibility-to-externs for -cc1Scott Linder2019-01-281-0/+3
| | | | | | | | | | | | | Introduce an option to request global visibility settings be applied to declarations without a definition or an explicit visibility, rather than the existing behavior of giving these default visibility. When the visibility of all or most extern definitions are known this allows for the same optimisations -fvisibility permits without updating source code to annotate all declarations. Differential Revision: https://reviews.llvm.org/D56868 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@352391 91177308-0d34-0410-b5e6-96231b3b80d8
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
* [LTO] Add option to enable LTOUnit splitting, and disable unless neededTeresa Johnson2019-01-111-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: Adds a new -f[no]split-lto-unit flag that is disabled by default to control module splitting during ThinLTO. It is automatically enabled for -fsanitize=cfi and -fwhole-program-vtables. The new EnableSplitLTOUnit codegen flag is passed down to llvm via a new module flag of the same name. Depends on D53890. Reviewers: pcc Subscribers: ormris, mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D53891 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350949 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenMP] Add flag for preventing the extension to 64 bits for the collapse ↵Gheorghe-Teodor Bercea2019-01-091-0/+5
| | | | | | | | | | | | | | | | loop counter Summary: Introduce a compiler flag for cases when the user knows that the collapsed loop counter can be safely represented using at most 32 bits. This will prevent the emission of expensive mathematical operations (such as the div operation) on the iteration variable using 64 bits where 32 bit operations are sufficient. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: hfinkel, kkwli0, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D55928 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350758 91177308-0d34-0410-b5e6-96231b3b80d8
* Move -add-plugin validation after -load was executed.Nico Weber2019-01-051-14/+1
| | | | | | | | Moves the code added in r350340 around a bit, to hopefully make the existing plugin tests pass when clang is built with examples enabled. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350451 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Implement lazy thread initialization for the interceptor ABI.Peter Collingbourne2019-01-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is similar to D55986 but for threads: a process with the interceptor hwasan library loaded might have some threads started by instrumented libraries and some by uninstrumented libraries, and we need to be able to run instrumented code on the latter. The solution is to perform per-thread initialization lazily. If a function needs to access shadow memory or add itself to the per-thread ring buffer its prologue checks to see whether the value in the sanitizer TLS slot is null, and if so it calls __hwasan_thread_enter and reloads from the TLS slot. The runtime does the same thing if it needs to access this data structure. This change means that the code generator needs to know whether we are targeting the interceptor runtime, since we don't want to pay the cost of lazy initialization when targeting a platform with native hwasan support. A flag -fsanitize-hwaddress-abi={interceptor,platform} has been introduced for selecting the runtime ABI to target. The default ABI is set to interceptor since it's assumed that it will be more common that users will be compiling application code than platform code. Because we can no longer assume that the TLS slot is initialized, the pthread_create interceptor is no longer necessary, so it has been removed. Ideally, lazy initialization should only cost one instruction in the hot path, but at present the call may cause us to spill arguments to the stack, which means more instructions in the hot path (or theoretically in the cold path if the spills are moved with shrink wrapping). With an appropriately chosen calling convention for the per-thread initialization function (TODO) the hot path should always need just one instruction and the cold path should need two instructions with no spilling required. Differential Revision: https://reviews.llvm.org/D56038 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350429 91177308-0d34-0410-b5e6-96231b3b80d8
* Validate -add-plugin arguments.Nico Weber2019-01-031-1/+15
| | | | | | | | | | -plugin already prints an error if the name of an unknown plugin is passed. -add-plugin used to silently ignore that, now it errors too. Differential Revision: https://reviews.llvm.org/D56273 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350340 91177308-0d34-0410-b5e6-96231b3b80d8
* Automatic variable initializationJF Bastien2018-12-181-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349442 91177308-0d34-0410-b5e6-96231b3b80d8
* [darwin] parse the SDK settings from SDKSettings.json if it exists andAlex Lorenz2018-12-171-0/+8
| | | | | | | | | | | | | | | | | | | | | pass in the -target-sdk-version to the compiler and backend This commit adds support for reading the SDKSettings.json file in the Darwin driver. This file is used by the driver to determine the SDK's version, and it uses that information to pass it down to the compiler using the new -target-sdk-version= option. This option is then used to set the appropriate SDK Version module metadata introduced in r349119. Note: I had to adjust the two ast tests as the SDKROOT environment variable on macOS caused SDK version to be picked up for the compilation of source file but not the AST. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55673 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349380 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement -frecord-command-line (-frecord-gcc-switches)Scott Linder2018-12-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Implement options in clang to enable recording the driver command-line in an ELF section. Implement a new special named metadata, llvm.commandline, to support frontends embedding their command-line options in IR/ASM/ELF. This differs from the GCC implementation in some key ways: * In GCC there is only one command-line possible per compilation-unit, in LLVM it mirrors llvm.ident and multiple are allowed. * In GCC individual options are separated by NULL bytes, in LLVM entire command-lines are separated by NULL bytes. The advantage of the GCC approach is to clearly delineate options in the face of embedded spaces. The advantage of the LLVM approach is to support merging multiple command-lines unambiguously, while handling embedded spaces with escaping. Differential Revision: https://reviews.llvm.org/D54487 Clang Differential Revision: https://reviews.llvm.org/D54489 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349155 91177308-0d34-0410-b5e6-96231b3b80d8
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | | Basic uses CodeGenOptions and should not depend on Frontend. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348827 91177308-0d34-0410-b5e6-96231b3b80d8
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-3/+3
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348755 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert some ObjC msgSends to runtime calls.Pete Cooper2018-12-081-0/+4
| | | | | | | | | | | | | | It is faster to directly call the ObjC runtime for methods such as alloc/allocWithZone instead of sending a message to those functions. This patch adds support for converting messages to alloc/allocWithZone to their equivalent runtime calls. Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions. Reviewed By: rjmccall https://reviews.llvm.org/D55349 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348687 91177308-0d34-0410-b5e6-96231b3b80d8
* [frontend][darwin] warn_stdlibcxx_not_found: supress warning for ↵Alex Lorenz2018-12-061-1/+7
| | | | | | | | | preprocessed input Addresses second post-commit feedback for r335081 from Nico git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348540 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] Add clang flag -fsanitize-address-use-odr-indicatorVitaly Buka2018-12-051-0/+5
| | | | | | | | | | Reviewers: eugenis, m.ostapenko, ygribov Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D55157 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348327 91177308-0d34-0410-b5e6-96231b3b80d8
* PTH-- Remove feature entirely-Erich Keane2018-12-041-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348266 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Provide -fvisibility-global-new-delete-hidden optionPetr Hosek2018-12-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | When the global new and delete operators aren't declared, Clang provides and implicit declaration, but this declaration currently always uses the default visibility. This is a problem when the C++ library itself is being built with non-default visibility because the implicit declaration will force the new and delete operators to have the default visibility unlike the rest of the library. The existing workaround is to use assembly to enforce the visiblity: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108 but that solution is not always available, e.g. in the case of of libFuzzer which is using an internal version of libc++ that's also built with -fvisibility=hidden where the existing behavior is causing issues. This change introduces a new option -fvisibility-global-new-delete-hidden which makes the implicit declaration of the global new and delete operators hidden. Differential Revision: https://reviews.llvm.org/D53787 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348234 91177308-0d34-0410-b5e6-96231b3b80d8
* [Analyzer] Actually check for -model-path being a directoryIlya Biryukov2018-12-031-5/+6
| | | | | | | The original patch (r348038) clearly contained a typo and checked for '-ctu-dir' twice. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348125 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Emit an error for invalid -analyzer-config inputsKristof Umann2018-11-301-16/+63
| | | | | | | Differential Revision: https://reviews.llvm.org/D53280 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348038 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Evaluate all non-checker config options before analysisKristof Umann2018-11-301-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348031 91177308-0d34-0410-b5e6-96231b3b80d8
* [-gmodules] Honor -fdebug-prefix-map in the debug info inside PCMs.Adrian Prantl2018-11-291-0/+6
| | | | | | | | | | | | This patch passes -fdebug-prefix-map (a feature for renaming source paths in the debug info) through to the per-module codegen options and adds the debug prefix map to the module hash. <rdar://problem/46045865> Differential Revision: https://reviews.llvm.org/D55037 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347926 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] Replace magic numbers with CodeGenOpt enumsSam Parker2018-11-261-6/+6
| | | | | | | | Use enum values from llvm/Support/CodeGen.h for the optimisation levels in CompilerInvocation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347577 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to ↵Calixte Denizet2018-11-171-0/+4
| | | | | | | | | | | | | | | | | | filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659) Summary: the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows. So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c. Reviewers: marco-c Reviewed By: marco-c Subscribers: cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D54600 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347144 91177308-0d34-0410-b5e6-96231b3b80d8
* Sink BuryPointer from Clang into LLVM for reuse thereDavid Blaikie2018-11-171-15/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347141 91177308-0d34-0410-b5e6-96231b3b80d8
* [codeview] Expose -gcodeview-ghash for global type hashingReid Kleckner2018-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Experience has shown that the functionality is useful. It makes linking optimized clang with debug info for me a lot faster, 20s to 13s. The type merging phase of PDB writing goes from 10s to 3s. This removes the LLVM cl::opt and replaces it with a metadata flag. After this change, users can do the following to use ghash: - add -gcodeview-ghash to compiler flags - replace /DEBUG with /DEBUG:GHASH in linker flags Reviewers: zturner, hans, thakis, takuto.ikuta Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D54370 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347072 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.Richard Smith2018-11-141-1/+1
| | | | | | | | | | | | | This unfortunately results in a substantial breaking change when switching to C++20, but it's not yet clear what / how much we should do about that. We may want to add a compatibility conversion from u8 string literals to const char*, similar to how C++98 provided a compatibility conversion from string literals to non-const char*, but that's not handled by this patch. The feature can be disabled in C++20 mode with -fno-char8_t. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@346892 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' ↵George Rimar2018-11-141-1/+17
| | | | | | | | | | | | | | | | | | | | option. The DWARF5 specification says(Appendix F.1): "The sections that do not require relocation, however, can be written to the relocatable object (.o) file but ignored by the linker or they can be written to a separate DWARF object (.dwo) file that need not be accessed by the linker." The first part describes a single file split DWARF feature and there is no way to trigger this behavior atm. Fortunately, no many changes are required to keep *.dwo sections in a .o, the patch does that. Differential revision: https://reviews.llvm.org/D52296 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@346837 91177308-0d34-0410-b5e6-96231b3b80d8
* DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.David Blaikie2018-11-131-0/+1
| | | | | | | | | | | | | | | Summary: This saves a lot of relocations in optimized object files (at the cost of some cost/increase in linked executable bytes), but gold's 32 bit gdb-index support has a bug ( https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't switch to this unconditionally. (& even if it weren't for that bug, one might argue that some users would want to optimize in one direction or the other - prioritizing object size or linked executable size) Differential Revision: https://reviews.llvm.org/D54243 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@346789 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert rL346644, rL346642: the added test ↵Calixte Denizet2018-11-121-4/+0
| | | | | | test/CodeGen/code-coverage-filter.c is failing under windows git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@346659 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-21 08:25:50 +0000