summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* [Objective-c] Stop attaching section "datacoal_nt" to global variables.Akira Hatanaka2016-02-111-1/+1
| | | | | | | | | | | | | The current macho linker just copies symbols in section datacoal_nt to section data, so it doesn't really matter whether or not section "datacoal_nt" is attached to the global variable. This is a follow-up to r250370, which made changes in llvm to stop putting functions and data in the *coal* sections. rdar://problem/24528611 llvm-svn: 260496
* Fix some Clang-tidy readability-redundant-control-flow warnings; other minor ↵Eugene Zelenko2016-02-102-88/+35
| | | | | | | | fixes. Differential revision: http://reviews.llvm.org/D17060 llvm-svn: 260414
* [Frontend] Handle ASTConsumer::shouldSkipFunctionBody via the MultiplexConsumer.Argyrios Kyrtzidis2016-02-091-0/+7
| | | | llvm-svn: 260252
* [ASTUnit] Change the parameter of ASTUnit::LoadFromCompilerInvocationAction ↵Argyrios Kyrtzidis2016-02-091-2/+2
| | | | | | to accept a more general FrontendAction. llvm-svn: 260251
* Simplify EnterTokenStream API to make it more robust for memory managementDavid Blaikie2016-02-091-4/+3
| | | | | | | | | | | | | | | While this won't help fix things like the bug that r260219 addressed, it seems like good tidy up to have anyway. (it might be nice if "makeArrayRef" always produced a MutableArrayRef & let it decay to an ArrayRef when needed - then I'd use that for the MutableArrayRefs in this patch) If we had std::dynarray I'd use that instead of unique_ptr+size_t, ideally (but then it'd have to be threaded down through the Preprocessor all the way - no idea how painful that would be) llvm-svn: 260246
* Fix possible OOB access found by buildbotAlexey Bataev2016-02-091-7/+8
| | | | llvm-svn: 260219
* Fixed preprocessed output of the first token for pragmas.Alexey Bataev2016-02-091-0/+9
| | | | | | | Clang did not expanded macros in the very first token of the pragmas during preprocessed output llvm-svn: 260211
* Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow ↵Samuel Antao2016-02-081-1/+18
| | | | | | | | specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
* [Frontend] Make the memory management of FrontendAction pointers explicit by ↵Argyrios Kyrtzidis2016-02-072-5/+5
| | | | | | using unique_ptr. llvm-svn: 260048
* Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized ↵Renato Golin2016-02-071-18/+1
| | | | | | | | code generation for different devices." This reverts commit r259985, as it still fails one buildbot. llvm-svn: 260036
* Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code ↵Samuel Antao2016-02-061-1/+18
| | | | | | | | generation for different devices. This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated. llvm-svn: 259985
* Revert r259977 - [OpenMP] Reorganize code to allow specialized code ↵Samuel Antao2016-02-061-18/+1
| | | | | | | | generation for different devices. It triggered some problem in the configuration related with zlib and exposed in the driver. llvm-svn: 259984
* [OpenMP] Reorganize code to allow specialized code generation for different ↵Samuel Antao2016-02-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | devices. Summary: Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation. This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it. In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done. In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not. Let me know comments suggestions you may have. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski Differential Revision: http://reviews.llvm.org/D16784 llvm-svn: 259977
* Eliminate an unnecessary enum, use the LLVM version. NFCPaul Robinson2016-02-051-4/+4
| | | | llvm-svn: 259950
* [PGO] cc1 option name change for profile instrumentationRong Xu2016-02-041-3/+22
| | | | | | | | | | | | This patch changes cc1 option -fprofile-instr-generate to an enum option -fprofile-instrument={clang|none}. It also changes cc1 options -fprofile-instr-generate= to -fprofile-instrument-path=. The driver level option -fprofile-instr-generate and -fprofile-instr-generate= remain intact. This change will pave the way to integrate new PGO instrumentation in IR level. Review: http://reviews.llvm.org/D16730 llvm-svn: 259811
* Move DebugInfoKind into its own header to cut the cyclic dependency edge ↵Benjamin Kramer2016-02-022-11/+10
| | | | | | from Driver to Frontend. llvm-svn: 259489
* Remove the egregious PCHContainer layering hack that doesn't seem to be ↵Benjamin Kramer2016-02-011-0/+3
| | | | | | necessary anymore. llvm-svn: 259355
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | r259192 post commit comment. llvm-svn: 259232
* Remove autoconf supportChris Bieneman2016-01-262-36/+0
| | | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "This is the way [autoconf] ends Not with a bang but a whimper." -T.S. Eliot Reviewers: chandlerc, grosbach, bob.wilson, echristo Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D16472 llvm-svn: 258862
* Do not define GXX_RTTI macro for C.Yunzhong Gao2016-01-261-1/+1
| | | | | | | | This is same as GCC behavior (tested with GCC 4.8.2). Differential Revision: http://reviews.llvm.org/D16365 llvm-svn: 258850
* [MS ABI] Allow a member pointers' converted type to changeDavid Majnemer2016-01-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Member pointers in the MS ABI are tricky for a variety of reasons. The size of a member pointer is indeterminate until the program reaches a point where the representation is required to be known. However, *pointers* to member pointers may exist without knowing the pointee type's representation. In these cases, we synthesize an opaque LLVM type for the pointee type. However, we can be in a situation where the underlying member pointer's representation became known mid-way through the program. To account for this, we attempted to manicure CodeGen's type-cache so that we can replace the opaque member pointer type with the real deal while leaving the pointer types unperturbed. This, unfortunately, is a problematic approach to take as we will violate CodeGen's invariants. These violations are mostly harmless but let's do the right thing instead: invalidate the type-cache if a member pointer's LLVM representation changes. This fixes PR26313. llvm-svn: 258839
* Use instance_properties instead of properties. NFC.Manman Ren2016-01-262-9/+12
| | | | | | | | | | | All current properties are instance properties. This is the second patch in a series of patches to support class properties in addition to instance properties in objective-c. rdar://23891898 llvm-svn: 258824
* [CUDA] Add -fcuda-allow-variadic-functions.Justin Lebar2016-01-261-0/+3
| | | | | | | | | | | | | | | | | Summary: Turns out the variadic function checking added in r258643 was too strict for some existing users; give them an escape valve. When -fcuda-allow-variadic-functions is passed, the front-end makes no attempt to disallow C-style variadic functions. Calls to va_arg are still not allowed. Reviewers: tra Subscribers: cfe-commits, jhen, echristo, bkramer Differential Revision: http://reviews.llvm.org/D16559 llvm-svn: 258822
* Fix -Wnull-conversion for long macros.Richard Trieu2016-01-261-43/+2
| | | | | | | | | Move the function to get a macro name from DiagnosticRenderer.cpp to Lexer.cpp so that other files can use it. Lexer now has two functions to get the immediate macro name, the newly added one is better for diagnostic purposes. Make -Wnull-conversion use this function for better NULL macro detection. llvm-svn: 258778
* Introduce -fsanitize-stats flag.Peter Collingbourne2016-01-162-2/+4
| | | | | | | | | This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
* Module debugging: Make the module format part of the module hash insteadAdrian Prantl2016-01-121-2/+5
| | | | | | | | | | of the file name. This is consistent with how other HeaderSearchOptions are handled. Due to the other inputs of the module hash (revision number) this is not really testable in a meaningful way. llvm-svn: 257520
* Accidentally removed part of the file header. Restoring it back.Ekaterina Romanova2016-01-101-1/+1
| | | | llvm-svn: 257291
* [modules] Make sure we always include the contents of private headers whenRichard Smith2016-01-081-9/+11
| | | | | | | | | | building a module. Prior to this change, the private header's content would only be included if the header were included by another header in the same module. If not (if the private header is only used by the .cc files of the module, or is included from outside the module via -Wno-private-header), a #include of that file would be silently ignored. llvm-svn: 257222
* Only instantiate a default argument once.John McCall2016-01-061-0/+6
| | | | | | | | | | | | | | | | | | | By storing the instantiated expression back in the ParmVarDecl, we remove the last need for separately storing the sub-expression of a CXXDefaultArgExpr. This makes PCH/Modules merging quite simple: CXXDefaultArgExpr records are serialized as references to the ParmVarDecl, and we ignore redundant attempts to overwrite the instantiated expression. This has some extremely marginal impact on user-facing semantics. However, the major effect is that it avoids IRGen errors about conflicting definitions due to lambdas in the argument being instantiated multiple times while sharing the same mangling. It should also slightly improve memory usage and module file size. rdar://23810407 llvm-svn: 256983
* [Driver] Add support for -fno-builtin-foo options.Chad Rosier2016-01-062-1/+28
| | | | | | | Addresses PR4941 and rdar://6756912. http://reviews.llvm.org/D15195 llvm-svn: 256937
* [OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-061-0/+24
| | | | | | | | | | | | device codegen. This patch attempts to fix the regressions identified when the patch was committed initially. Thanks to Michael Liao for identifying the fix in the offloading metadata generation related with side effects in evaluation of function arguments. llvm-svn: 256933
* Avoid assert failure on some invalid cc1 options.Douglas Katzman2016-01-061-8/+19
| | | | | | | | Addressing review comment in D13221. Differential Revision: http://reviews.llvm.org/D15882 llvm-svn: 256897
* [OpenMP] Revert rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-051-24/+0
| | | | | | | | device codegen. It was causing two regression, so I'm reverting until the cause is found. llvm-svn: 256858
* [OpenMP] Offloading descriptor registration and device codegen.Samuel Antao2016-01-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In order to offloading work properly two things need to be in place: - a descriptor with all the offloading information (device entry functions, and global variable) has to be created by the host and registered in the OpenMP offloading runtime library. - all the device functions need to be emitted for the device and a convention has to be in place so that the runtime library can easily map the host ID of an entry point with the actual function in the device. This patch adds support for these two things. However, only entry functions are being registered given that 'declare target' directive is not yet implemented. About offloading descriptor: The details of the descriptor are explained with more detail in http://goo.gl/L1rnKJ. Basically the descriptor will have fields that specify the number of devices, the pointers to where the device images begin and end (that will be defined by the linker), and also pointers to a the begin and end of table whose entries contain information about a specific entry point. Each entry has the type: ``` struct __tgt_offload_entry{ void *addr; char *name; int64_t size; }; ``` and will be implemented in a pre determined (ELF) section `.omp_offloading.entries` with 1-byte alignment, so that when all the objects are linked, the table is in that section with no padding in between entries (will be like a C array). The code generation ensures that all `__tgt_offload_entry` entries are emitted in the same order for both host and device so that the runtime can have the corresponding entries in both host and device in same index of the table, and efficiently implement the mapping. The resulting descriptor is registered/unregistered with the runtime library using the calls `__tgt_register_lib` and `__tgt_unregister_lib`. The registration is implemented in a high priority global initializer so that the registration happens always before any initializer (that can potentially include target regions) is run. The driver flag -omptargets= was created to specify a comma separated list of devices the user wants to support so that the new functionality can be exercised. Each device is specified with its triple. About target codegen: The target codegen is pretty much straightforward as it reuses completely the logic of the host version for the same target region. The tricky part is to identify the meaningful target regions in the device side. Unlike other programming models, like CUDA, there are no already outlined functions with attributes that mark what should be emitted or not. So, the information on what to emit is passed in the form of metadata in host bc file. This requires a new option to pass the host bc to the device frontend. Then everything is similar to what happens in CUDA: the global declarations emission is intercepted to check to see if it is an "interesting" declaration. The difference is that instead of checking an attribute, the metadata information in checked. Right now, there is only a form of metadata to pass information about the device entry points (target regions). A class `OffloadEntriesInfoManagerTy` was created to manage all the information and queries related with the metadata. The metadata looks like this: ``` !omp_offload.info = !{!0, !1, !2, !3, !4, !5, !6} !0 = !{i32 0, i32 52, i32 77426347, !"_ZN2S12r1Ei", i32 479, i32 13, i32 4} !1 = !{i32 0, i32 52, i32 77426347, !"_ZL7fstatici", i32 461, i32 11, i32 5} !2 = !{i32 0, i32 52, i32 77426347, !"_Z9ftemplateIiET_i", i32 444, i32 11, i32 6} !3 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 99, i32 11, i32 0} !4 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 272, i32 11, i32 3} !5 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 127, i32 11, i32 1} !6 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 159, i32 11, i32 2} ``` The fields in each metadata entry are (in sequence): Entry 1) an ID of the type of metadata - right now only zero is used meaning "OpenMP target region". Entry 2) a unique ID of the device where the input source file that contain the target region lives. Entry 3) a unique ID of the file where the input source file that contain the target region lives. Entry 4) a mangled name of the function that encloses the target region. Entries 5) and 6) line and column number where the target region was found. Entry 7) is the order the entry was emitted. Entry 2) and 3) are required to distinguish files that have the same function name. Entry 4) is required to distinguish different instances of the same declaration (usually templated ones) Entries 5) and 6) are required to distinguish the particular target region in body of the function (it is possible that a given target region is not an entry point - if clause can evaluate always to zero - and therefore we need to identify the "interesting" target regions. ) This patch replaces http://reviews.llvm.org/D12306. Reviewers: ABataev, hfinkel, tra, rjmccall, sfantao Subscribers: FBrygidyn, piotr.rak, Hahnfeld, cfe-commits Differential Revision: http://reviews.llvm.org/D12614 llvm-svn: 256842
* [ptr-traits] Add #includes of headers rather than forward declarationsChandler Carruth2015-12-301-0/+1
| | | | | | | | | | | | | | for types which are used as pointees in PointerUnions, PointerIntPairs, and DenseMap pointer keys. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. I think this is the last patch for getting Clang clean here!!! llvm-svn: 256615
* Refactor: Simplify boolean conditional return statements in lib/FrontendAlexander Kornienko2015-12-281-3/+1
| | | | | | | | | | | | | | Summary: Use clang-tidy to simplify boolean conditional return statements Reviewers: alexfh Subscribers: alexfh, cfe-commits Patch by Richard Thomson! Differential Revision: http://reviews.llvm.org/D10016 llvm-svn: 256496
* Fix C++ support on recent DragonFly BSD releasesDimitry Andric2015-12-271-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: [ Copied from https://llvm.org/bugs/show_bug.cgi?id=25597 ] Clang support for DragonFly BSD is lagging a bit, resulting in poor support for c++. DragonFlyBSD is unique in that it has two base compilers. At the time of the last Clang update for DragonFly, these compilers were GCC 4.4 and GCC 4.7 (default). With DragonFly Release 4.2, GCC 4.4 was replaced with GCC 5.0, partially because the C++11 support of GCC 4.7 was incomplete. The DragonFly project will Release version 4.4 soon. This patch updates the Clang driver to use libstdc++ from GCC 5.2 The support for falling back to the alternate compiler was removed for two reasons: 1) The last release to use GCC 4.7 is DF 4.0 which has already reached EOL 2) GCC 4.7 libstdc++ is insufficient for many "ports" Therefore, I think it is reasonable that the development version of clang expects GCC 5.2 to be in place and not try to fall back to another compiler. The attached patch will do this. The Tools.cpp file was signficantly modified to fix the linking which had been changed somewhere along the line. The rest of the changes should be self-explanatory. Reviewers: joerg, rsmith, davide Subscribers: jrmarino, davide, cfe-commits Differential Revision: http://reviews.llvm.org/D15166 llvm-svn: 256467
* Some minor correction based on David Blaikie post-commit code review for ↵Ekaterina Romanova2015-12-241-3/+2
| | | | | | r255281. llvm-svn: 256396
* [clang-cl] Add support for /BreproDavid Majnemer2015-12-211-0/+2
| | | | | | | | | | | | The /Brepro flag controls whether or not the compiler should embed timestamps into the object file. Object files which do not embed timestamps are not suitable for incremental linking but are suitable for hermetic build systems and staged self-hosts of clang. A normal clang spelling of this flag has been added, -mincremental-linker-compatible. llvm-svn: 256204
* Recommit CC1 part of debugger tuning; pass through setting from driver to LLVM.Paul Robinson2015-12-191-0/+7
| | | | | | | | | Reapplies r256063, except instead of frugally re-using an LLVM enum, we define a Clang enum, to avoid exposing too much LLVM interface. Differential Revision: http://reviews.llvm.org/D15650 llvm-svn: 256078
* Revert r256063, it's killing clang-tools-extraPaul Robinson2015-12-191-7/+0
| | | | llvm-svn: 256066
* CC1 part of debugger tuning; pass through setting from driver to LLVM.Paul Robinson2015-12-181-0/+7
| | | | | | Differential Revision: http://reviews.llvm.org/D15650 llvm-svn: 256063
* Update for llvm API change.Rafael Espindola2015-12-162-2/+0
| | | | llvm-svn: 255838
* [x86] Exclusion of incorrect include headers paths for MCU targetAndrey Bokhanko2015-12-161-0/+2
| | | | | | | | Exclusion of /usr/include and /usr/local/include headers paths for MCU target. Differential Revision: http://reviews.llvm.org/D14954 llvm-svn: 255766
* Cross-DSO control flow integrity (Clang part).Evgeniy Stepanov2015-12-151-0/+1
| | | | | | | | | | | | | | Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
* [libclang] Add a flag to create the precompiled preamble on the first parse.Benjamin Kramer2015-12-151-16/+19
| | | | | | | | | | | | | | | | | | | | | Summary: The current default is to create the preamble on the first reparse, aka second parse. This is useful for clients that do not want to block when opening a file because serializing the preamble takes a bit of time. However, this makes the reparse much more expensive and that may be on the critical path as it's the first interaction a user has with the source code. YouCompleteMe currently optimizes for the first code interaction by parsing the file twice when loaded. That's just unnecessarily slow and this flag helps to avoid that. Reviewers: doug.gregor, klimek Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15490 llvm-svn: 255635
* Do not generate DW_TAG_imported_module for anonymous namespaces (even ↵Ekaterina Romanova2015-12-101-0/+3
| | | | | | | | | | nested) for all the platforms except PS4. For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artificial attribute. Differential Revision: http://reviews.llvm.org/D12624 llvm-svn: 255281
* Module file extensions: pass a Sema through to the extension writer.Douglas Gregor2015-12-082-1/+3
| | | | | | | | Module file extensions are likely to need access to Sema/Preprocessor/ASTContext, and cannot get it through other sources. llvm-svn: 255065
* [diagnostics] Avoid crashes while printing macro backtracesReid Kleckner2015-12-081-19/+64
| | | | | | | | | | | | | | | | | | | When attempting to map a source into a given level of macro expansion, this code was ignoring the possibility that the start and end of the range might take wildly different paths through the tree of macro expansions. It was assuming that the begin spelling location would always precede the end spelling location, which is false. A macro can easily transpose its arguments. This also fixes a related issue where there are extra macro arguments between the begin location and the end location. In this situation, we now highlight the entire macro invocation. Pair programmed with Richard Smith. Fixes PR12818. llvm-svn: 254981
* [ThinLTO] Option to invoke ThinLTO backend passes and importingTeresa Johnson2015-12-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds new option -fthinlto-index=<file> to invoke the LTO pipeline along with function importing via clang using the supplied function summary index file. This supports invoking the parallel ThinLTO backend processes in a distributed build environment via clang. Additionally, this causes the module linker to be invoked on the bitcode file being compiled to perform any necessary promotion and renaming of locals that are exported via the function summary index file. Add a couple tests that confirm we get expected errors when we try to use the new option on a file that isn't bitcode, or specify an invalid index file. The tests also confirm that we trigger the expected function import pass. Depends on D15024 Reviewers: joker.eph, dexonsmith Subscribers: joker.eph, davidxl, cfe-commits Differential Revision: http://reviews.llvm.org/D15025 llvm-svn: 254927
OpenPOWER on IntegriCloud