Commit Graph

437 Commits

Author SHA1 Message Date
Jan Korous 986202fad4 [clang][test][NFC] Use more widely supported sanitizer for file dependency tests
The tests aren't concerned at all by the actual sanitizer - only by blacklist being reported as a dependency.
We're unfortunately limited by platform support for any particular sanitizer but we can at least use one that is widely supported.

Post-commit review:
https://reviews.llvm.org/D72729
2020-01-14 12:55:11 -08:00
Karl-Johan Karlsson 073cdb2390 [clang][test] Minor fixes in testcase absolute-paths-symlinks.c
This is a follow up commit to address post-commit comment in D70527.
2019-12-26 09:33:21 +01:00
Karl-Johan Karlsson e8efac4b15 [clang] Fix the canonicalization of paths in -fdiagnostics-absolute-paths
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
2019-12-20 09:16:33 +01:00
Teresa Johnson c8e0bb3b2c [LTO] Support for embedding bitcode section during LTO
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
2019-12-12 12:34:19 -08:00
Alexey Bader cb30ad728f [SYCL] Add support for auxiliary triple specification to Frontend
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>
2019-12-11 12:40:43 +03:00
Leonard Chan e278c138a9 [Sema] Add MacroQualified case for FunctionTypeUnwrapper
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
2019-11-12 16:22:13 -08:00
Dávid Bolvanský 5c50109bb5 Fixed more -Wreturn-type tests 2019-11-09 18:13:51 +01:00
Dávid Bolvanský 1da13237a4 [Diagnostics] Try to improve warning message for -Wreturn-type
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
2019-11-09 17:54:58 +01:00
Jan Korous d52cff8836 Revert "Reland "[clang] Report sanitizer blacklist as a dependency in cc1""
This reverts commit cae4a28864.
2019-11-08 14:28:30 -08:00
Jan Korous cae4a28864 Reland "[clang] Report sanitizer blacklist as a dependency in cc1"
This reverts commit 3182027282.
2019-11-08 13:55:00 -08:00
Jan Korous 6d28588cc0 Reland "[clang] Report sanitizer blacklist as a dependency in cc1"
This reverts commit 9b8413ac6e.
2019-11-08 13:54:28 -08:00
Abel Kocsis 9b8413ac6e Revert "Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1"""
This reverts commit 3182027282.
2019-11-08 14:08:15 +01:00
Abel Kocsis 3182027282 Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1""
This reverts commit 6b45e1bc11.
2019-11-08 14:00:44 +01:00
Jeremy Morse 6b45e1bc11 Revert "[clang] Report sanitizer blacklist as a dependency in cc1"
This reverts commit 03b84e4f6d.

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.
2019-11-08 12:07:42 +00:00
Jan Korous 03b84e4f6d [clang] Report sanitizer blacklist as a dependency in cc1
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
2019-11-07 14:06:43 -08:00
Evandro Menezes 215da6606c [clang][llvm] Obsolete Exynos M1 and M2 2019-10-30 15:02:59 -05:00
Yaxun (Sam) Liu 68f5ca4e19 [HIP] Add option -fgpu-allow-device-init
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
2019-10-22 16:06:20 -04:00
Reid Kleckner 5e866e411c Add -fgnuc-version= to control __GNUC__ and other GCC macros
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
2019-10-10 21:04:25 +00:00
Teresa Johnson 2024ea148c Fix buildbot failure from r373217 (don't match metadata id exactly)
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
2019-09-30 17:26:48 +00:00
Teresa Johnson 57dbfe194c [Clang] Use -main-file-name for source filename if not set
-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
2019-09-30 15:05:35 +00:00
Fangrui Song e6d423fe03 [test] Use %clang_cc1 instead of %clang -cc1
llvm-svn: 373043
2019-09-27 05:37:06 +00:00
Lubos Lunak 3425a89676 fix build, adjust test also for Windows path separator
Introduced in 1e9c1d2b7b.

llvm-svn: 372263
2019-09-18 21:41:45 +00:00
Lubos Lunak 1e9c1d2b7b actually also compile output in tests for -frewrite-includes
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
2019-09-18 19:12:14 +00:00
Lubos Lunak 533434fc72 make -frewrite-includes also rewrite conditions in #if/#elif
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
2019-09-18 19:09:41 +00:00
Lubos Lunak a507a5ec8f do not emit -Wunused-macros warnings in -frewrite-includes mode (PR15614)
-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
2019-09-16 19:18:37 +00:00
Manoj Gupta 41d9d5092a Reland r371785: Add -Wpoison-system-directories warning
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
2019-09-13 18:00:51 +00:00
Manoj Gupta 38f6b3fd8d Revert r371785.
r371785 is causing fails on clang-hexagon-elf buildbots.

llvm-svn: 371799
2019-09-13 00:28:37 +00:00
Manoj Gupta 4fe2732161 Add -Wpoison-system-directories warning
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
2019-09-12 22:36:13 +00:00
Reid Kleckner 38e033bf33 Re-land Remove REQUIRES:shell from tests that pass for me on Windows
This reverts r371497 (git commit 3d7e9ab7b9)

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
2019-09-10 20:15:45 +00:00
James Henderson 3d7e9ab7b9 Revert Remove REQUIRES:shell from tests that pass for me on Windows
This reverts r371478 (git commit a9980f60ce)

llvm-svn: 371497
2019-09-10 08:48:33 +00:00
Reid Kleckner a9980f60ce Remove REQUIRES:shell from tests that pass for me on Windows
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
2019-09-10 00:50:32 +00:00
Jian Cai 16fa8b0970 Reland "[ARM] push LR before __gnu_mcount_nc"
This relands r369147 with fixes to unit tests.

https://reviews.llvm.org/D65019

llvm-svn: 369173
2019-08-16 23:30:16 +00:00
Anastasia Stulova 88ed70e247 [OpenCL] Rename lang mode flag for C++ mode
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
2019-07-25 11:04:29 +00:00
Sunil Srivastava 85d667fcb6 Renamed and changed the wording of warn_cconv_ignored
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
2019-07-17 20:41:26 +00:00
Leonard Chan e6d2c8dde6 [clang][NewPM] Fixing remaining -O0 tests that are broken under new PM
- 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
2019-06-19 17:41:30 +00:00
Alex Lorenz 6e2d36b60b Add clang source minimizer that reduces source to directives
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
2019-06-03 22:59:17 +00:00
Igor Kudrin 0de4e935bb Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on 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
2019-05-24 04:46:22 +00:00
Nico Weber 9b2830b46e lld-link, clang: Treat non-existent input files as possible spellos for 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
2019-05-23 17:58:33 +00:00
Louis Dionne e97b5f5cf3 [clang][Darwin] Refactor header search path logic into the driver
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
2019-05-21 17:48:04 +00:00
Leonard Chan bcb9bbc011 Add target triple to test.
llvm-svn: 360465
2019-05-10 20:07:47 +00:00
Leonard Chan dc5d975906 Fix and test for assertion error in P41835.
llvm-svn: 360448
2019-05-10 18:05:15 +00:00
Leonard Chan c72aaf62d3 Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"
Updated with fix for read of uninitialized memory.

llvm-svn: 360109
2019-05-07 03:20:17 +00:00
Leonard Chan ef2dc25a96 Revert "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"
This reverts commit fc40cbd9d8.

llvm-svn: 359859
2019-05-03 03:28:06 +00:00
Leonard Chan fc40cbd9d8 [Attribute/Diagnostics] Print macro if definition is an attribute declaration
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
2019-05-02 20:38:14 +00:00
Richard Smith 4e8144a0d1 [verify] Add support for location markers in directives.
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 // 
  // 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
2019-04-13 04:33:39 +00:00
Leonard Chan 8f7caae00a [Fixed Point Arithmetic] Fixed Point and Integer Conversions
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
2019-03-06 00:28:43 +00:00
Ganesh Gopalasubramanian 4f171d2761 [X86] AMD znver2 enablement
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
2019-02-26 17:15:36 +00:00
Leonard Chan ce1d4f1bec [Fixed Point Arithmetic] Fixed Point Comparisons
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
2019-02-21 20:50:09 +00:00
David Zarzycki 4a0a64ac1d Hot fix two test regressions (%T vs %t)
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
2019-02-03 15:49:11 +00:00
Nico Weber c16cc77917 Replace uses of %T with %t in from previous frontend test differential
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
2019-02-02 23:16:30 +00:00