summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* [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 llvm-svn: 349380
* [ASTImporter] Add importer specific lookupGabor Marton2018-12-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are certain cases when normal C/C++ lookup (localUncachedLookup) does not find AST nodes. E.g.: Example 1: template <class T> struct X { friend void foo(); // this is never found in the DC of the TU. }; Example 2: // The fwd decl to Foo is not found in the lookupPtr of the DC of the // translation unit decl. struct A { struct Foo *p; }; In these cases we create a new node instead of returning with the old one. To fix it we create a new lookup table which holds every node and we are not interested in any C++ specific visibility considerations. Simply, we must know if there is an existing Decl in a given DC. Reviewers: a_sidorin, a.sidorin Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D53708 llvm-svn: 349351
* 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 llvm-svn: 349155
* Fix up diagnostics.Richard Trieu2018-12-141-1/+0
| | | | | | | | | | | Move some diagnostics around between Diagnostic*Kinds.td files. Diagnostics used in multiple places were moved to DiagnosticCommonKinds.td. Diagnostics listed in the wrong place (ie, Sema diagnostics listed in DiagnosticsParseKinds.td) were moved to the correct places. One diagnostic split into two so that the diagnostic string is in the .td file instead of in code. Cleaned up the diagnostic includes after all the changes. llvm-svn: 349125
* Move PCHContainerOperations from Frontend to SerializationRichard Trieu2018-12-123-71/+1
| | | | | | | Fix a layering violation. Frontend depends on Serialization, so anything used by both should be in Serialization. llvm-svn: 348907
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-113-34/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* 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 llvm-svn: 348755
* 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 llvm-svn: 348687
* [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 llvm-svn: 348540
* Move detection of libc++ include dirs to Driver on MacOSIlya Biryukov2018-12-051-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
* [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 llvm-svn: 348327
* PTH-- Remove feature entirely-Erich Keane2018-12-047-755/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 348266
* [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 llvm-svn: 348234
* [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. llvm-svn: 348125
* [analyzer] Emit an error for invalid -analyzer-config inputsKristof Umann2018-11-301-16/+63
| | | | | | Differential Revision: https://reviews.llvm.org/D53280 llvm-svn: 348038
* [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 llvm-svn: 348031
* [-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 llvm-svn: 347926
* Add Hurd target to Clang driver (2/2)Kristina Brooks2018-11-291-0/+3
| | | | | | | | | | | | | | | This adds Hurd toolchain support to Clang's driver in addition to handling translating the triple from Hurd-compatible form to the actual triple registered in LLVM. (Phabricator was stripping the empty files from the patch so I manually created them) Patch by sthibaul (Samuel Thibault) Differential Revision: https://reviews.llvm.org/D54379 llvm-svn: 347833
* [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. llvm-svn: 347577
* [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 llvm-svn: 347144
* Sink BuryPointer from Clang into LLVM for reuse thereDavid Blaikie2018-11-173-18/+5
| | | | llvm-svn: 347141
* [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 llvm-svn: 347072
* Fix combining pragma __debug dump & parser_crash with -EDavid Blaikie2018-11-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Previously these would be transformed into annotation tokens and the preprocessor would then assume they were real tokens with source locations and assert/UB. Other pragmas that produce annotation tokens aren't a problem because they aren't handled if the parser isn't hooked up - ParsePragma.cpp registers those handlers & isn't run for pure preprocessing. So they're treated as unknown pragmas & printed verbatim by the preprocessor. Perhaps these pragmas should be treated the same way? But they got mixed in with other __debug pragmas that do need to be handled during preprocessing. The third __debug pragma that produces an annotation token is 'captured' - which had its own fix for this issue - by not inserting the annotation token in the first place if it detected that it was in preprocessing mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more general one in Frontend/PrintPreprocessedOutput.cpp. llvm-svn: 346928
* [c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.Richard Smith2018-11-142-5/+5
| | | | | | | | | | | | | 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. llvm-svn: 346892
* [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 llvm-svn: 346837
* 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 llvm-svn: 346789
* Revert "Make clang-based tools find libc++ on MacOS"Jonas Devlieghere2018-11-122-9/+10
| | | | | | This breaks the LLDB bots. llvm-svn: 346675
* Revert rL346644, rL346642: the added test ↵Calixte Denizet2018-11-121-4/+0
| | | | | | test/CodeGen/code-coverage-filter.c is failing under windows llvm-svn: 346659
* Make clang-based tools find libc++ on MacOSIlya Biryukov2018-11-122-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When they read compiler args from compile_commands.json. This change allows to run clang-based tools, like clang-tidy or clangd, built from head using the compile_commands.json file produced for XCode toolchains. On MacOS clang can find the C++ standard library relative to the compiler installation dir. The logic to do this was based on resource dir as an approximation of where the compiler is installed. This broke the tools that read 'compile_commands.json' and don't ship with the compiler, as they typically change resource dir. To workaround this, we now use compiler install dir detected by the driver to better mimic the behavior of the original compiler when replaying the compilations using other tools. Reviewers: sammccall, arphaman, EricWF Reviewed By: sammccall Subscribers: ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54310 llvm-svn: 346652
* [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to ↵Calixte Denizet2018-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | filter the files to instrument with gcov Summary: These options are taking regex separated by colons to filter files. - if both are empty then all files are instrumented - if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented - if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented - if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented - this patch is a follow-up of https://reviews.llvm.org/D52033 Reviewers: marco-c, vsk Reviewed By: marco-c, vsk Subscribers: cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D52034 llvm-svn: 346642
* Pass the function type instead of the return type to FunctionDecl::CreateJonas Devlieghere2018-11-111-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix places where the return type of a FunctionDecl was being used in place of the function type FunctionDecl::Create() takes as its T parameter the type of function that should be created, not the return type. Passing in the return type looks to have been copypasta'd around a bit, but the number of correct usages outweighs the incorrect ones so I've opted for keeping what T is the same and fixing up the call sites instead. This fixes a crash in Clang when attempting to compile the following snippet of code with -fblocks -fsanitize=function -x objective-c++ (my original repro case): void g(void(^)()); void f() { __block int a = 0; g(^(){ a++; }); } as well as the following which only requires -fsanitize=function -x c++: void f(char * buf) { __builtin_os_log_format(buf, ""); } Patch by: Ben (bobsayshilol) Differential revision: https://reviews.llvm.org/D53263 llvm-svn: 346601
* [Frontend/Modules] Show diagnostics on prebuilt module configuration ↵David Blaikie2018-11-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | mismatch too The current version only emits the below error for a module (attempted to be loaded) from the `prebuilt-module-path`: ``` error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch] ``` With this change, if the prebuilt module is used, we allow the proper diagnostic behind the configuration mismatch to be shown. ``` error: POSIX thread support was disabled in PCH file but is currently enabled error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch] ``` (A few lines later an error is emitted anyways, so there is no reason not to complain for configuration mismatches if a config mismatch is found and kills the build.) Reviewed By: dblaikie Tags: #clang Differential Revision: https://reviews.llvm.org/D53334 llvm-svn: 346439
* Reapply "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Benjamin Kramer2018-11-051-0/+3
| | | | | | | | | | | | | This reverts commit r345963. We have a path forward now. Original commit message: The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 346130
* Add /Zc:DllexportInlines option to clang-clTakuto Ikuta2018-11-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This CL adds /Zc:DllexportInlines flag to clang-cl. When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables. By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables. On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below. These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied * https://chromium-review.googlesource.com/c/chromium/src/+/1212379 * https://chromium-review.googlesource.com/c/v8/v8/+/1186017 Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e | config | build time | speedup | build dir size | | with patch, PCH on, debug | 1h10m0s | x1.13 | 35.6GB | | without patch, PCH on, debug | 1h19m17s | | 49.0GB | | with patch, PCH off, debug | 1h15m45s | x1.16 | 33.7GB | | without patch, PCH off, debug | 1h28m10s | | 52.3GB | | with patch, PCH on, release | 1h13m13s | x1.22 | 26.2GB | | without patch, PCH on, release | 1h29m57s | | 37.5GB | | with patch, PCH off, release | 1h23m38s | x1.32 | 23.7GB | | without patch, PCH off, release | 1h50m50s | | 38.7GB | This patch reduced obj size and the number of exported symbols largely, that improved link time too. e.g. link time stats of blink_core.dll become like below | | cold disk cache | warm disk cache | | with patch, PCH on, debug | 71s | 30s | | without patch, PCH on, debug | 111s | 48s | This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats. Bug: https://bugs.llvm.org/show_bug.cgi?id=33628 Reviewers: hans, thakis, rnk, javed.absar Reviewed By: hans Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman Differential Revision: https://reviews.llvm.org/D51340 llvm-svn: 346069
* Change -fsanitize-address-poison-class-member-array-new-cookie to ↵Filipe Cabecinhas2018-11-021-4/+4
| | | | | | | | | | | | | | -fsanitize-address-poison-custom-array-cookie Handle it in the driver and propagate it to cc1 Reviewers: rjmccall, kcc, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52615 llvm-svn: 346001
* [analyzer] New flag to print all -analyzer-config optionsKristof Umann2018-11-021-0/+1
| | | | | | | | A new -cc1 flag is avaible for the said purpose: -analyzer-config-help Differential Revision: https://reviews.llvm.org/D53296 llvm-svn: 345989
* [OPENMP][NVPTX]Improve emission of the globalized variables forAlexey Bataev2018-11-021-0/+8
| | | | | | | | | | | | | | | | | | | target/teams/distribute regions. Target/teams/distribute regions exist for all the time the kernel is executed. Thus, if the variable is declared in their context and then escape it, we can allocate global memory statically instead of allocating it dynamically. Patch captures all the globalized variables in target/teams/distribute contexts, merges them into the records, one per each target region. Those records are then joined into the union, one per compilation unit (to save the global memory). Those units are organized into 2 x dimensional arrays, where the first dimension is the number of blocks per SM and the second one is the number of SMs. Runtime functions manage this global memory space between the executing teams. llvm-svn: 345978
* Revert "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Ilya Biryukov2018-11-021-3/+0
| | | | | | | | | | This reverts commit r345803 and r345915 (a follow-up fix to r345803). Reason: r345803 blocks our internal integrate because of the new warnings showing up in too many places. The fix is actually correct, we will reland it after figuring out how to integrate properly. llvm-svn: 345963
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-013-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* Fix typo in comment.Richard Smith2018-11-011-1/+1
| | | | llvm-svn: 345805
* Fix regression in behavior of clang -x c++-header -fmodule-name=XXXRichard Smith2018-11-011-0/+3
| | | | | | | | | | | | -fsyntax-only. The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 345803
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-308-17/+17
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [VFS] Add property 'fallthrough' that controls fallback to real file system.Volodymyr Sapsai2018-10-261-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Default property value 'true' preserves current behavior. Value 'false' can be used to create VFS "root", file system that gives better control over which files compiler can use during compilation as there are no unpredictable accesses to real file system. Non-fallthrough use case changes how we treat multiple VFS overlay files. Instead of all of them being at the same level just above a real file system, now they are nested and subsequent overlays can refer to files in previous overlays. Change is done both in LLVM and Clang, corresponding LLVM commit is r345431. rdar://problem/39465552 Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits, hiraditya Differential Revision: https://reviews.llvm.org/D50539 llvm-svn: 345432
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-0/+2
| | | | | | | | | | | | 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
* [AArch64] Branch Protection and Return Address Signing B Key SupportLuke Cheeseman2018-10-251-2/+20
| | | | | | | | | | | - Add support for -mbranch-protection=<type>[+<type>]* where - <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*] - The protection emits relevant function attributes - sign-return-address=<scope> - sign-return-address-key=<key> - branch-protection llvm-svn: 345273
* Driver,CodeGen: introduce support for Swift CFString layoutSaleem Abdulrasool2018-10-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the runtime ABI for CoreFoundation. This controls the language interoperability. In particular, this is relevant for generating the CFConstantString classes (primarily through the `__builtin___CFStringMakeConstantString` builtin) which construct a reference to the "CFObject"'s `isa` field. This type differs between swift 4.1 and 4.2+. Valid values for the new option include: - objc [default behaviour] - enable ObjectiveC interoperability - swift-4.1 - enable interoperability with swift 4.1 - swift-4.2 - enable interoperability with swift 4.2 - swift-5.0 - enable interoperability with swift 5.0 - swift [alias] - target the latest swift ABI Furthermore, swift 4.2+ changed the layout for the CFString when building CoreFoundation *without* ObjectiveC interoperability. In such a case, a field was added to the CFObject base type changing it from: <{ const int*, int }> to <{ uintptr_t, uintptr_t, uint64_t }>. In swift 5.0, the CFString type will be further adjusted to change the length from a uint32_t on everything but BE LP64 targets to uint64_t. Note that the default behaviour for clang remains unchanged and the new layout must be explicitly opted into via `-fcf-runtime-abi=swift*`. llvm-svn: 345222
* [VFS] Remove 'ignore-non-existent-contents' attribute for YAML-based VFS.Volodymyr Sapsai2018-10-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 'ignore-non-existent-contents' stopped working after r342232 in a way that the actual attribute value isn't used and it works as if it is always `true`. Common use case for VFS iteration is iterating through files in umbrella directories for modules. Ability to detect if some VFS entries point to non-existing files is nice but non-critical. Instead of adding back support for `'ignore-non-existent-contents': false` I am removing the attribute, because such scenario isn't used widely enough and stricter checks don't provide enough value to justify the maintenance. rdar://problem/45176119 Reviewers: bruno Reviewed By: bruno Subscribers: hiraditya, dexonsmith, sammccall, cfe-commits Differential Revision: https://reviews.llvm.org/D53228 llvm-svn: 345212
* [clang] Introduce new completion context typesKadir Cetinkaya2018-10-241-5/+7
| | | | | | | | | | | | | | Summary: New name suggestions were being used in places where existing names should have been used, this patch tries to fix some of those situations. Reviewers: sammccall Reviewed By: sammccall Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D53191 llvm-svn: 345152
* Add support for -mno-tls-direct-seg-refs to ClangKristina Brooks2018-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch exposes functionality added in rL344723 to the Clang driver/frontend as a flag and adds appropriate metadata. Driver tests pass: ``` ninja check-clang-driver -snip- Expected Passes : 472 Expected Failures : 3 Unsupported Tests : 65 ``` Odd failure in CodeGen tests but unrelated to this: ``` ninja check-clang-codegen -snip- /SourceCache/llvm-trunk-8.0/tools/clang/test/CodeGen/builtins-wasm.c:87:10: error: cannot compile this builtin function yet -snip- Failing Tests (1): Clang :: CodeGen/builtins-wasm.c Expected Passes : 1250 Expected Failures : 2 Unsupported Tests : 120 Unexpected Failures: 1 ``` Original commit: [X86] Support for the mno-tls-direct-seg-refs flag Allows to disable direct TLS segment access (%fs or %gs). GCC supports a similar flag, it can be useful in some circumstances, e.g. when a thread context block needs to be updated directly from user space. More info and specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145 Patch by nruslan (Ruslan Nikolaev). Differential Revision: https://reviews.llvm.org/D53102 llvm-svn: 344739
* Remove top-level using declaration from header files, as these aliases leak.Sam McCall2018-10-121-1/+1
| | | | | | | | | | Reviewers: ilya-biryukov Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D53135 llvm-svn: 344337
OpenPOWER on IntegriCloud