summaryrefslogtreecommitdiffstats
path: root/clang/test/Frontend
Commit message (Collapse)AuthorAgeFilesLines
* [clang][test] Minor fixes in testcase absolute-paths-symlinks.cKarl-Johan Karlsson2019-12-261-3/+5
| | | | This is a follow up commit to address post-commit comment in D70527.
* [clang] Fix the canonicalization of paths in -fdiagnostics-absolute-pathsKarl-Johan Karlsson2019-12-201-0/+15
| | | | | | | | | | | | | | | | In the current implementation of clang the canonicalization of paths in diagnostic messages (when using -fdiagnostics-absolute-paths) only works if the symbolic link is in the directory part of the filename, not if the file itself is a symbolic link to another file. This patch adds support to canonicalize the complete path including the file. Reviewers: rsmith, hans, rnk, ikudrin Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D70527
* [LTO] Support for embedding bitcode section during LTOTeresa Johnson2019-12-121-0/+74
| | | | | | | | | | | | | | | | | | | Summary: This adds support for embedding bitcode in a binary during LTO. The libLTO gains supports the `-lto-embed-bitcode` flag. The option allows users of the LTO library to embed a bitcode section. For example, LLD can pass the option via `ld.lld -mllvm=-lto-embed-bitcode`. This feature allows doing something comparable to `clang -c -fembed-bitcode`, but on the (LTO) linker level. Having bitcode alongside native code has many use-cases. To give an example, the MacOS linker can create a `-bitcode_bundle` section containing bitcode. Also, having this feature built into LLVM is an alternative to 3rd party tools such as [[ https://github.com/travitch/whole-program-llvm | wllvm ]] or [[ https://github.com/SRI-CSL/gllvm | gllvm ]]. As with these tools, this feature simplifies creating "whole-program" llvm bitcode files, but in contrast to wllvm/gllvm it does not rely on a specific llvm frontend/driver. Patch by Josef Eisl <josef.eisl@oracle.com> Reviewers: #llvm, #clang, rsmith, pcc, alexshap, tejohnson Reviewed By: tejohnson Subscribers: tejohnson, mehdi_amini, inglorion, hiraditya, aheejin, steven_wu, dexonsmith, dang, cfe-commits, llvm-commits, #llvm, #clang Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68213
* [SYCL] Add support for auxiliary triple specification to FrontendAlexey Bader2019-12-111-0/+5
| | | | | | | | | | | | | | | | | Summary: Add host predefined macros to compilation for SYCL device, which is required for pre-processing host specific includes (e.g. system headers). Reviewers: ABataev, jdoerfert Subscribers: ebevhan, Anastasia, cfe-commits, keryell, Naghasan, Fznamznon Tags: #clang Differential Revision: https://reviews.llvm.org/D71286 Signed-off-by: Alexey Bader <alexey.bader@intel.com>
* [Sema] Add MacroQualified case for FunctionTypeUnwrapperLeonard Chan2019-11-121-0/+4
| | | | | | | | | | | | | | | | | | This is a fix for PR43315. An assertion error is hit for this minimal example: ``` //clang -cc1 -triple x86_64-- -S tstVMStructRC-min.cpp int (a b)(); // Assertion `Chunk.Kind == DeclaratorChunk::Function' failed. ``` This is because we do not cover the case in the FunctionTypeUnwrapper where it receives a MacroQualifiedType. We have not run into this earlier because this is a unique case where the __attribute__ contains both __cdecl__ and __regparm__ (in that order), and we are compiling for x86_64. Changing the architecture or the order of __cdecl__ and __regparm__ does not raise the assertion. Differential Revision: https://reviews.llvm.org/D67992
* Fixed more -Wreturn-type testsDávid Bolvanský2019-11-091-1/+1
|
* [Diagnostics] Try to improve warning message for -Wreturn-typeDávid Bolvanský2019-11-091-3/+3
| | | | | | | | | | | | | | Summary: I agree with https://easyaspi314.github.io/gcc-vs-clang.html?fbclid=IwAR1VA0qxiWVUusOQUv5z7JESS7ZpeJy-UqAI5mnJscofGLqXcqeErIUB2gU, current warning message is not very good. We should try to improve it.. Reviewers: rsmith, aaron.ballman, easyaspi314 Reviewed By: aaron.ballman Subscribers: arphaman, Quuxplusone, mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69762
* Revert "Reland "[clang] Report sanitizer blacklist as a dependency in cc1""Jan Korous2019-11-081-0/+17
| | | | This reverts commit cae4a28864f4e8a55920e2b94e2cd43617902dec.
* Reland "[clang] Report sanitizer blacklist as a dependency in cc1"Jan Korous2019-11-081-17/+0
| | | | This reverts commit 3182027282c59c51d5080d83365917fccd695854.
* Reland "[clang] Report sanitizer blacklist as a dependency in cc1"Jan Korous2019-11-081-0/+17
| | | | This reverts commit 9b8413ac6e56e7a6e0ba884773d13bcf9414bd43.
* Revert "Revert "Revert "[clang] Report sanitizer blacklist as a dependency ↵Abel Kocsis2019-11-081-17/+0
| | | | | | in cc1""" This reverts commit 3182027282c59c51d5080d83365917fccd695854.
* Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1""Abel Kocsis2019-11-081-0/+17
| | | | This reverts commit 6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8.
* Revert "[clang] Report sanitizer blacklist as a dependency in cc1"Jeremy Morse2019-11-081-17/+0
| | | | | | | | | | This reverts commit 03b84e4f6d0e1c04f22d69cc445f36e1f713beb4. This breaks dfsan tests with a linking failure, in for example this build: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24312 Reverting this patch locally makes those tests succeed.
* [clang] Report sanitizer blacklist as a dependency in cc1Jan Korous2019-11-071-0/+17
| | | | | | | | Previously these were reported from the driver which blocked clang-scan-deps from getting the full set of dependencies from cc1 commands. Also the default sanitizer blacklist that is added in driver was never reported as a dependency. I introduced -fsanitize-system-blacklist cc1 option to keep track of which blacklists were user-specified and which were added by driver and clang -MD now also reports system blacklists as dependencies. Differential Revision: https://reviews.llvm.org/D69290
* [clang][llvm] Obsolete Exynos M1 and M2Evandro Menezes2019-10-301-1/+1
|
* [HIP] Add option -fgpu-allow-device-initYaxun (Sam) Liu2019-10-221-0/+8
| | | | | | | | | | | | | | Add this option to allow device side class type global variables with non-trivial ctor/dtor. device side init/fini functions will be emitted, which will be executed by HIP runtime when the fat binary is loaded/unloaded. This feature is to facilitate implementation of device side sanitizer which requires global vars with non-trival ctors. By default this option is disabled. Differential Revision: https://reviews.llvm.org/D69268
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 llvm-svn: 374449
* Fix buildbot failure from r373217 (don't match metadata id exactly)Teresa Johnson2019-09-301-1/+1
| | | | | | | Fix this failure by ignoring the id of the metadata being checked: http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/3046/consoleFull#-21332887158254eaf0-7326-4999-85b0-388101f2d404 llvm-svn: 373237
* [Clang] Use -main-file-name for source filename if not setTeresa Johnson2019-09-301-0/+7
| | | | | | | | | | | | | | | | | | | -main-file-name is currently used to set the source name used in debug information. If the source filename is "-" and -main-file-name is set, then use the filename also for source_filename and ModuleID of the output. The argument is generally used outside the internal clang calls when running clang in a wrapper like icecc which gives the source via stdin but still wants to get a object file with the original source filename both in debug info and IR code. Patch by: the_jk (Joel Klinghed) Differential Revision: https://reviews.llvm.org/D67592 llvm-svn: 373217
* [test] Use %clang_cc1 instead of %clang -cc1Fangrui Song2019-09-272-3/+3
| | | | llvm-svn: 373043
* fix build, adjust test also for Windows path separatorLubos Lunak2019-09-182-2/+2
| | | | | | Introduced in 1e9c1d2b7bfc. llvm-svn: 372263
* actually also compile output in tests for -frewrite-includesLubos Lunak2019-09-1811-61/+74
| | | | | | | | | Checking that the created output matches something is nice, but this should also check whether the output makes sense. Differential Revision: https://reviews.llvm.org/D63979 llvm-svn: 372250
* make -frewrite-includes also rewrite conditions in #if/#elifLubos Lunak2019-09-182-8/+152
| | | | | | | | | | | | | | | Those conditions may use __has_include, which needs to be rewritten. The existing code has already tried to rewrite just __has_include, but it didn't work with macro expansion, so e.g. Qt's "#define QT_HAS_INCLUDE(x) __has_include(x)" didn't get handled properly. Since the preprocessor run knows what each condition evaluates to, just rewrite the entire condition. This of course requires that the -frewrite-include pass has the same setup as the following compilation, but that has always been the requirement. Differential Revision: https://reviews.llvm.org/D63508 llvm-svn: 372248
* do not emit -Wunused-macros warnings in -frewrite-includes mode (PR15614)Lubos Lunak2019-09-161-1/+4
| | | | | | | | | | | -frewrite-includes calls PP.SetMacroExpansionOnlyInDirectives() to avoid macro expansions that are useless in that mode, but this can lead to -Wunused-macros false positives. As -frewrite-includes does not emit normal warnings, block -Wunused-macros too. Differential Revision: https://reviews.llvm.org/D65371 llvm-svn: 372026
* Reland r371785: Add -Wpoison-system-directories warningManoj Gupta2019-09-136-0/+29
| | | | | | | | | | | | | | | | | | | | When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. This is reland of r371785 with a fix to test file. Patch by: denik (Denis Nikitin) llvm-svn: 371878
* Revert r371785.Manoj Gupta2019-09-136-27/+0
| | | | | | r371785 is causing fails on clang-hexagon-elf buildbots. llvm-svn: 371799
* Add -Wpoison-system-directories warningManoj Gupta2019-09-126-0/+27
| | | | | | | | | | | | | | | | | | When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. Patch by: denik (Denis Nikitin) llvm-svn: 371785
* Re-land Remove REQUIRES:shell from tests that pass for me on WindowsReid Kleckner2019-09-101-8/+6
| | | | | | | | | | | | This reverts r371497 (git commit 3d7e9ab7b9f8c53aa41420c54970f0fb421004a2) Reorder `not` with `env` in these two tests so they pass: Driver/rewrite-map-in-diagnostics.c Index/crash-recovery-modules.m. This will not be necessary after D66531 lands. llvm-svn: 371552
* Revert Remove REQUIRES:shell from tests that pass for me on WindowsJames Henderson2019-09-101-6/+8
| | | | | | This reverts r371478 (git commit a9980f60ce083fa6d5fd03c12c58ca0b293e3d60) llvm-svn: 371497
* Remove REQUIRES:shell from tests that pass for me on WindowsReid Kleckner2019-09-101-8/+6
| | | | | | | | | | | | | I see in the history for some of these tests REQUIRES:shell was used as a way to disable tests on Windows because they are flaky there. I tried not to re-enable such tests, but it's possible that I missed some and this will re-enable flaky tests on Windows. If so, we should disable them with UNSUPPORTED:system-windows and add a comment that they are flaky there. So far as I can tell, the lit internal shell is capable of running all of these tests, and we shouldn't use REQUIRES:shell as a proxy for Windows. llvm-svn: 371478
* Reland "[ARM] push LR before __gnu_mcount_nc"Jian Cai2019-08-161-1/+1
| | | | | | | | This relands r369147 with fixes to unit tests. https://reviews.llvm.org/D65019 llvm-svn: 369173
* [OpenCL] Rename lang mode flag for C++ modeAnastasia Stulova2019-07-252-2/+3
| | | | | | | | | | | | Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++ or -std=clc++/-std=CLC++. This aligns with OpenCL C conversion and removes ambiguity with OpenCL C++. Differential Revision: https://reviews.llvm.org/D65102 llvm-svn: 367008
* Renamed and changed the wording of warn_cconv_ignoredSunil Srivastava2019-07-171-1/+1
| | | | | | | | As discussed in D64780 the wording of this warning message is being changed to say 'is not supported' instead of 'ignored', and the diag ID itself is being changed to warn_cconv_not_supported. llvm-svn: 366368
* [clang][NewPM] Fixing remaining -O0 tests that are broken under new PMLeonard Chan2019-06-195-7/+132
| | | | | | | | | | | | | | - CodeGen/flatten.c will fail under new PM becausec the new PM AlwaysInliner seems to intentionally inline functions but not call sites marked with alwaysinline (D23299) - Tests that check remarks happen to check them for the inliner which is not turned on at O0. These tests just check that remarks work, but we can make separate tests for the new PM with -O1 so we can turn on the inliner and check the remarks with minimal changes. Differential Revision: https://reviews.llvm.org/D62225 llvm-svn: 363846
* Add clang source minimizer that reduces source to directivesAlex Lorenz2019-06-031-0/+14
| | | | | | | | | | | | | | | | | | | | | that might affect the dependency list for a compilation This commit introduces a dependency directives source minimizer to clang that minimizes header and source files to the minimum necessary preprocessor directives for evaluating includes. It reduces the source down to #define, #include, The source minimizer works by lexing the input with a custom fast lexer that recognizes the preprocessor directives it cares about, and emitting those directives in the minimized source. It ignores source code, comments, and normalizes whitespace. It gives up and fails if seems any directives that it doesn't recognize as valid (e.g. #define 0). In addition to the source minimizer this patch adds a -print-dependency-directives-minimized-source CC1 option that allows you to invoke the minimizer from clang directly. Differential Revision: https://reviews.llvm.org/D55463 llvm-svn: 362459
* Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on ↵Igor Kudrin2019-05-242-1/+10
| | | | | | | | | | | | | | Windows. If the source file path contains directory junctions, and we resolve them when printing diagnostic messages, these paths look independent for an IDE. For example, both Visual Studio and Visual Studio Code open separate editors for such paths, which is not only inconvenient but might even result in losing changes made in one of them. Differential Revision: https://reviews.llvm.org/D59415 llvm-svn: 361598
* lld-link, clang: Treat non-existent input files as possible spellos for ↵Nico Weber2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | option flags OptTable treats arguments starting with / that aren't a known option as filenames. This means lld-link's and clang-cl's typo correction for unknown flags didn't do spell checking for misspelled options that start with /. I first tried changing OptTable, but that got pretty messy, see PR41787 comments 2 and 3. Instead, let lld-link's and clang's (including clang-cl's) "file not found" diagnostic check if a non-existent file looks like it could be a mis-spelled option, and if so add a "did you mean" suggestion to the "file not found" diagnostic. While here, make formatting of a few diagnostics a bit more self-consistent. Fixes PR41787. Differential Revision: https://reviews.llvm.org/D62276 llvm-svn: 361518
* [clang][Darwin] Refactor header search path logic into the driverLouis Dionne2019-05-211-6/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This commit moves the logic for determining system, resource and C++ header search paths from CC1 to the driver. This refactor has already been made for several platforms, but Darwin had been left behind. This refactor tries to implement the previous search path logic with perfect accuracy. In particular, the order of all include paths inside CC1 and all paths that were skipped because nonexistent are conserved after the refactor. This change was also tested against a code base of significant size and revealed no problems. Reviewers: jfb, arphaman Subscribers: nemanjai, javed.absar, kbarton, christof, jkorous, dexonsmith, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61963 llvm-svn: 361278
* Add target triple to test.Leonard Chan2019-05-101-1/+1
| | | | llvm-svn: 360465
* Fix and test for assertion error in P41835.Leonard Chan2019-05-101-0/+6
| | | | llvm-svn: 360448
* Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an ↵Leonard Chan2019-05-071-0/+15
| | | | | | | | attribute declaration" Updated with fix for read of uninitialized memory. llvm-svn: 360109
* Revert "[Attribute/Diagnostics] Print macro if definition is an attribute ↵Leonard Chan2019-05-031-15/+0
| | | | | | | | declaration" This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d. llvm-svn: 359859
* [Attribute/Diagnostics] Print macro if definition is an attribute declarationLeonard Chan2019-05-021-0/+15
| | | | | | | | | | | | | If an address_space attribute is defined in a macro, print the macro instead when diagnosing a warning or error for incompatible pointers with different address_spaces. We allow this for all attributes (not just address_space), and for multiple attributes declared in the same macro. Differential Revision: https://reviews.llvm.org/D51329 llvm-svn: 359826
* [verify] Add support for location markers in directives.Richard Smith2019-04-132-0/+23
| | | | | | | | | | | | | | | A marker (matching /#[A-Za-z0-9_-]/) is specified by attaching a comment containing the marker to the line at which the diagnostic is expected, and then can be referenced from an expected-* directive after an @: foo // #1 // expected-error@#1 {{undeclared identifier 'foo'}} The intent is for markers to be used in situations where relative line numbers are currently used, to avoid the need to renumber when the test case is rearranged. llvm-svn: 358326
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-063-194/+367
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [X86] AMD znver2 enablementGanesh Gopalasubramanian2019-02-261-0/+1
| | | | | | | | | | | | | | | | | This patch enables the following 1) AMD family 17h "znver2" tune flag (-march, -mcpu). 2) ISAs that are enabled for "znver2" architecture. 3) For the time being, it uses the znver1 scheduler model. 4) Tests are updated. 5) This patch is the clang counterpart to D58343 Reviewers: craig.topper Tags: #clang Differential Revision: https://reviews.llvm.org/D58344 llvm-svn: 354899
* [Fixed Point Arithmetic] Fixed Point ComparisonsLeonard Chan2019-02-211-0/+378
| | | | | | | | | This patch implements fixed point comparisons with other fixed point types and integers. This also provides constant expression evaluation for them. Differential Revision: https://reviews.llvm.org/D57219 llvm-svn: 354621
* Hot fix two test regressions (%T vs %t)David Zarzycki2019-02-032-2/+2
| | | | | | | | | | | | | Different Unix "errno" values are returned for the following scenarios: $ echo test > /tmp/existingFile/impossibleDir/impossibleFile "Not a directory" $ echo test > /tmp/nonexistentDir/impossibleFile "No such file or directory" This fixes the regression introduced by r352971 / D57592. llvm-svn: 352996
* Replace uses of %T with %t in from previous frontend test differentialNico Weber2019-02-022-2/+2
| | | | | | | | | | | | | | | After committing a change I had made to a few frontend tests, it was pointed out to me that %T is being deprecated in LLVM in favor of %t. This change simply converts usages of %T to %t while maintaining the integrity of the test. Previous revision where this discussion took place: https://reviews.llvm.org/D50563 Differential Revision: https://reviews.llvm.org/D57592 Patch from Justice Adams <justice.adams@sony.com>! llvm-svn: 352971
* Provide reason messages for unviable inliningYevgeny Rouban2019-02-011-1/+1
| | | | | | | | | | | | | InlineCost's isInlineViable() is changed to return InlineResult instead of bool. This provides messages for failure reasons and allows to get more specific messages for cases where callsites are not viable for inlining. Reviewed By: xbolva00, anemet Differential Revision: https://reviews.llvm.org/D57089 llvm-svn: 352849
OpenPOWER on IntegriCloud