Commit Graph

1229 Commits

Author SHA1 Message Date
Ulrich Weigand 48b40834dc [SystemZ] Support z15 processor name
The recently announced IBM z15 processor implements the architecture
already supported as "arch13" in LLVM.  This patch adds support for
"z15" as an alternate architecture name for arch13.

Corrsponding LLVM support was committed as rev. 372435.

llvm-svn: 372436
2019-09-20 23:06:03 +00:00
Kito Cheng 42fe2fc8c9 [RISCV] Add option aliases: -mcmodel=medany and -mcmodel=medlow
RISC-V GCC use -mcmodel=medany and -mcmodel=medlow, but LLVM use
-mcmodel=small and -mcmodel=medium.

Add those two option aliases for provide same user interface between
GCC and LLVM.

Reviewed By: lenary

Differential Revision: https://reviews.llvm.org/D67066

llvm-svn: 372080
2019-09-17 08:19:17 +00:00
Kito Cheng 6455938441 [RISCV] Define __riscv_cmodel_medlow and __riscv_cmodel_medany correctly
RISC-V LLVM was only implement small/medlow code model, so it defined
__riscv_cmodel_medlow directly without check.

Now, we have medium/medany code model in RISC-V back-end, it should
define according the actually code model.

Reviewed By: lewis-revill

Differential Revision: https://reviews.llvm.org/D67065

llvm-svn: 372078
2019-09-17 08:09:56 +00:00
Volodymyr Sapsai fdb83b5055 Fix up a test updated in r371655 - require case-insensitive file system.
On case-sensitive file systems include with wrong case is not found instead of
showing a warning.

llvm-svn: 371665
2019-09-11 21:19:27 +00:00
Volodymyr Sapsai 2f84361684 Fix -Wnonportable-include-path suppression for header maps with absolute paths.
In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover
the case when clang finds a file through a header map but doesn't remap
the lookup filename because the target path is an absolute path. As a
result, -Wnonportable-include-path suppression for header maps
introduced in r301592 wasn't triggered.

Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter
`MappedName` to track the filename remapping. This way we can handle
both relative and absolute paths in header maps, and account for their
specific properties, like filename remapping being a property preserved
across lookups in multiple directories.

rdar://problem/39516483

Reviewers: dexonsmith, bruno

Reviewed By: dexonsmith

Subscribers: jkorous, cfe-commits, ributzka

Differential Revision: https://reviews.llvm.org/D58094

llvm-svn: 371655
2019-09-11 20:39:04 +00:00
Roger Ferrer Ibanez 8e87396307 [RISCV] Default to ilp32d/lp64d in RISC-V Linux
When running clang as a native compiler in RISC-V Linux the flag
-mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the
default there.

Differential Revision: https://reviews.llvm.org/D65634

llvm-svn: 371494
2019-09-10 07:57:36 +00:00
Justin Hibbits 3dac214273 Add -m(no)-spe to clang
Summary:
r337347 added support for the Signal Processing Engine (SPE) to LLVM.
This follows that up with the clang side.

This adds -mspe and -mno-spe, to match GCC.

Subscribers: nemanjai, kbarton, cfe-commits

Differential Revision: https://reviews.llvm.org/D49754

llvm-svn: 371066
2019-09-05 13:38:46 +00:00
Craig Topper 5a43fdd313 [X86] Remove what little support we had for MPX
-Deprecate -mmpx and -mno-mpx command line options
-Remove CPUID detection of mpx for -march=native
-Remove MPX from all CPUs
-Remove MPX preprocessor define

I've left the "mpx" string in the backend so we don't fail on old IR, but its not connected to anything.

gcc has also deprecated these command line options. https://www.phoronix.com/scan.php?page=news_item&px=GCC-Patch-To-Drop-MPX

Differential Revision: https://reviews.llvm.org/D66669

llvm-svn: 370393
2019-08-29 18:09:02 +00:00
Aaron Ballman 2ed4573e8f Allow standards-based attributes to have leading and trailing underscores.
This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation.

llvm-svn: 369033
2019-08-15 18:35:44 +00:00
Richard Smith dac3ea4eb3 Add __has_builtin support for builtin function-like type traits.
Summary:
Previously __has_builtin(__builtin_*) would return false for
__builtin_*s that we modeled as keywords rather than as functions
(because they take type arguments). With this patch, all builtins
that are called with function-call-like syntax return true from
__has_builtin (covering __builtin_* and also the __is_* and __has_* type
traits and the handful of similar builtins without such a prefix).

Update the documentation on __has_builtin and on type traits to match.
While doing this I noticed the type trait documentation was out of date
and incomplete; that's fixed here too.

Reviewers: aaron.ballman

Subscribers: jfb, kristina, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66100

llvm-svn: 368785
2019-08-14 02:30:11 +00:00
Pengfei Wang e28cbbd5d4 [X86] Support -march=tigerlake
Support -march=tigerlake for x86.
Compare with Icelake Client, It include 4 more new features ,they are
avx512vp2intersect, movdiri, movdir64b, shstk.

Patch by Xiang Zhang (xiangzhangllvm)

Differential Revision: https://reviews.llvm.org/D65840

llvm-svn: 368543
2019-08-12 01:29:46 +00:00
Reid Kleckner 50fcf7285e Don't diagnose errors when a file matches an include component
This regressed in r368322, and was reported as PR42948 and on the
mailing list. The fix is to ignore the specific error code for this
case. The problem doesn't seem to reproduce on Windows, where a
different error code is used instead.

llvm-svn: 368475
2019-08-09 19:49:14 +00:00
Ilya Biryukov b455fc429f [Preprocessor] Always discard body of #define if we failed to parse it
Summary:
Preivously we would only discard it if we failed to parse parameter lists.
If we do not consume the body, parser sees tokens inside directive. In
turn, this leads to spurious diagnostics and a crash in TokenBuffer, see
the added tests.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65517

llvm-svn: 367530
2019-08-01 09:10:37 +00:00
Sander de Smalen 405c999d97 [AArch64] Disable __ARM_FEATURE_SVE without ACLE.
The Arm C Language Extensions for SVE document specifies that 
__ARM_FEATURE_SVE should be set when the compiler supports SVE and
implements all the extensions described in the document.

This is currently not yet the case, so the feature should be disabled
until the compiler can provide all the extensions as described.

Reviewers: c-rhodes, rengolin, rovka, ktkachov

Reviewed By: rengolin

Differential Revision: https://reviews.llvm.org/D65404

llvm-svn: 367301
2019-07-30 10:14:39 +00:00
Erich Keane 46441fdb3c Implement P1771
As passed in the Cologne meeting and treated by Core as a DR,
[[nodiscard]] was applied to constructors so that they can be diagnosed
in cases where the user forgets a variable name for a type.

The intent is to enable the library to start using this on the
constructors of scope_guard/lock_guard.

Differential Revision: https://reviews.llvm.org/D64914

llvm-svn: 367027
2019-07-25 15:10:56 +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
Rainer Orth 2da6eea07c [clang, test] Fix Clang :: Headers/max_align.c on 64-bit SPARC
Clang :: Headers/max_align.c currently FAILs on 64-bit SPARC:

  error: 'error' diagnostics seen but not expected: 
    File /vol/llvm/src/clang/dist/test/Headers/max_align.c Line 12: static_assert failed due to requirement '8 == _Alignof(max_align_t)' ""
  1 error generated.

This happens because SuitableAlign isn't defined for SPARCv9 unlike SPARCv8
(which uses the default of 64 bits).  gcc's sparc/sparc.h has

  #define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64)

This patch sets SuitableAlign to match and updates the corresponding testcase.

Tested on sparcv9-sun-solaris2.11.

Differential Revision: https://reviews.llvm.org/D64487

llvm-svn: 366820
2019-07-23 16:24:00 +00:00
Aaron Ballman 1f5712ebb5 Revert the change to the [[nodiscard]] feature test macro value.
This value only gets bumped once both P1301 and P1771 are implemented.

llvm-svn: 366682
2019-07-22 12:49:28 +00:00
Aaron Ballman 3bef014e7d Implement P1301R4, which allows specifying an optional message on the [[nodiscard]] attribute.
This also bumps the attribute feature test value and introduces the notion of a C++2a extension warning.

llvm-svn: 366626
2019-07-20 07:56:34 +00:00
Alex Bradbury e078967adf [RISCV] Hard float ABI support
The RISC-V hard float calling convention requires the frontend to:

* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s)
* Track usage of GPRs and FPRs in order to gate the above, and to
determine when signext/zeroext attributes must be added to integer
scalars

This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.

Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.

Re-landed after backing out 366450 due to missed hunks.

Differential Revision: https://reviews.llvm.org/D60456

llvm-svn: 366480
2019-07-18 18:29:59 +00:00
Alex Bradbury 9b732fe99b Revert "[RISCV] Hard float ABI support" r366450
The commit was missing a few hunks. Will fix and recommit.

llvm-svn: 366454
2019-07-18 16:13:17 +00:00
Alex Bradbury fc3aa2ab48 [RISCV] Hard float ABI support
The RISC-V hard float calling convention requires the frontend to:

* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s) * Track usage of GPRs and FPRs in order to gate the
above, and to
determine when signext/zeroext attributes must be added to integer
scalars

This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.

Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.

Differential Revision: https://reviews.llvm.org/D60456

llvm-svn: 366450
2019-07-18 15:33:41 +00:00
Nathan Lanza 49e14cefbe Change a lit test to permit vendor specific clang version
A test manually checks for the string `__VERSION__ "Clang`. This needs
to permit vendor specific variants.

llvm-svn: 366166
2019-07-16 02:05:52 +00:00
Nathan Lanza 50f0c82453 Allow for vendor prefixes in a list test
Summary:
Preprocessor/init.c contains a line that explicitly checks for the
string

__VERSION__ "Clang{{.*}}

It's valid to have a toolchain configured to emit a vendor prefix
before the word Clang. e.g.

__VERSION__ "Vendor Clang{{.*}}

Subscribers: fedor.sergeev, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64772

llvm-svn: 366159
2019-07-16 00:57:50 +00:00
Sylvestre Ledru 56799837a4 Update __VERSION__ to remove the hardcoded 4.2.1 version
Summary:
Just like in https://reviews.llvm.org/D56803
for -dumpversion

Reviewers: rnk

Reviewed By: rnk

Subscribers: dexonsmith, lebedev.ri, hubert.reinterpretcast, xbolva00, fedor.sergeev, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63048

llvm-svn: 366091
2019-07-15 17:47:22 +00:00
Alexandros Lamprineas 951bb68ce2 [TargetParser][ARM] Account dependencies when processing target features
Teaches ARM::appendArchExtFeatures to account dependencies when processing
target features: i.e. when you say -march=armv8.1-m.main+mve.fp+nofp it
means mve.fp should get discarded too. (Split from D63936)

Differential Revision: https://reviews.llvm.org/D64048

llvm-svn: 366031
2019-07-14 20:31:15 +00:00
JF Bastien fff5dc0b17 Support __seg_fs and __seg_gs on x86
Summary:
GCC supports named address spaces macros:
  https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

clang does as well with address spaces:
  https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments

Add the __seg_fs and __seg_gs macros for compatibility with GCC.

<rdar://problem/52944935>

Subscribers: jkorous, dexonsmith, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64676

llvm-svn: 366028
2019-07-14 18:33:51 +00:00
Sylvestre Ledru 21a92a8a55 This reverts commit 632a36bfcfc8273c1861f04ff6758d863c47c784.
Some targets such as Python 2.7.16 still use VERSION in
their builds. Without VERSION defined, the source code
has syntax errors.

Reverting as it will probably break many other things.

Noticed by Sterling Augustine

llvm-svn: 365992
2019-07-13 06:27:35 +00:00
Sylvestre Ledru 603580216f Remove __VERSION__
Summary:
It has been introduced in 2011 for gcc compat:
ad1a4c6e89
it is probably time to remove it


Reviewers: rnk, dexonsmith

Reviewed By: rnk

Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64062

llvm-svn: 365962
2019-07-12 21:45:08 +00:00
Ulrich Weigand b98bf60ef7 [SystemZ] Add support for new cpu architecture - arch13
This patch series adds support for the next-generation arch13
CPU architecture to the SystemZ backend.

This includes:
- Basic support for the new processor and its features.
- Support for low-level builtins mapped to new LLVM intrinsics.
- New high-level intrinsics in vecintrin.h.
- Indicate support by defining  __VEC__ == 10303.

Note: No currently available Z system supports the arch13
architecture.  Once new systems become available, the
official system name will be added as supported -march name.

llvm-svn: 365933
2019-07-12 18:14:51 +00:00
Reid Kleckner fa52674ac0 Fix has_attribute.cpp test on Windows after r364102
llvm-svn: 364108
2019-06-21 22:28:52 +00:00
Richard Smith 5050a8da18 Fix __has_cpp_attribute expansion to produce trailing L and (where
necessary) leading whitespace.

Simplify unit test and extend to cover no_unique_address attribute.

llvm-svn: 364102
2019-06-21 20:20:21 +00:00
Aaron Puchert 2b285c664d Fix tests after r363749
We changed -Wmissing-prototypes there, which was used in these tests via
-Weverything.

llvm-svn: 363754
2019-06-18 23:40:17 +00:00
Rainer Orth abccb1ad89 Clang :: Sema/wchar.c has long been failing on Solaris:
error: 'error' diagnostics expected but not seen: 
    File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: initializing wide char array with non-wide string literal
  error: 'error' diagnostics seen but not expected: 
    File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 20: array initializer must be an initializer list
    File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: array initializer must be an initializer list

It turns out the definition is wrong, as can be seen in GCC's gcc/config/sol2.h:

  /* wchar_t is called differently in <wchar.h> for 32 and 64-bit
     compilations.  This is called for by SCD 2.4.1, p. 6-83, Figure 6-65
     (32-bit) and p. 6P-10, Figure 6.38 (64-bit).  */
  
  #undef WCHAR_TYPE
  #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int")

The following patch implements this, and at the same time corrects the wint_t
definition which is the same:

  /* Same for wint_t.  See SCD 2.4.1, p. 6-83, Figure 6-66 (32-bit).  There's
     no corresponding 64-bit definition, but this is what Solaris 8
     <iso/wchar_iso.h> uses.  */
  
  #undef WINT_TYPE
  #define WINT_TYPE (TARGET_64BIT ? "int" : "long int")

Clang :: Preprocessor/wchar_t.c and Clang :: Sema/format-strings.c need to
be adjusted to account for that.

Tested on i386-pc-solaris2.11, x86_64-pc-solaris2.11, and x86_64-pc-linux-gnu.

Differential Revision: https://reviews.llvm.org/D62944

llvm-svn: 363612
2019-06-17 20:21:25 +00:00
Hubert Tong a2c2d731db [CUDA] Fix grep pattern in cuda-types.cu
Summary:
vertical-line is not a BRE special character.

POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\|`
is undefined. This patch uses EREs instead.

Additionally, the pattern is further fixed so that `SIZEOF` and `WIDTH`
macros are checked.

Reviewers: jlebar, daltenty, xingxue, jasonliu, tra

Reviewed By: tra

Subscribers: jfb, jsji, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63029

llvm-svn: 362991
2019-06-10 22:28:20 +00:00
Sjoerd Meijer 4ea248eb56 [ARM] Add ACLE feature macros for MVE
If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined
to a value which has bit 0 set for integer MVE, and bit 1 set for
floating-point MVE.

(Floating-point MVE implies integer MVE, so if this macro is defined
at all then it will be set to 1 or 3, never 2.)

Patch mostly by Simon Tatham

Differential Revision: https://reviews.llvm.org/D60710

llvm-svn: 362806
2019-06-07 15:20:56 +00:00
Simon Tatham 5d66f2b0af [ARM] Fix bugs introduced by the fp64/d32 rework.
Change D60691 caused some knock-on failures that weren't caught by the
existing tests. Firstly, selecting a CPU that should have had a
restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs
and no double precision) could give the unrestricted version, because
`ARM::getFPUFeatures` returned a list of features including subtracted
ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw
away all the ones that didn't start with `+`. Secondly, the
preprocessor macros didn't reliably match the actual compilation
settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as
if hardware FP was available, because the list of features on the cc1
command line would include things like `+vfp4`,`-vfp4d16` and clang
didn't realise that one of those cancelled out the other.

I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so
that it returns a list that enables every FP-related feature
compatible with the selected FPU and disables every feature not
compatible, which is more verbose but means clang doesn't have to
understand the dependency relationships between the backend features.
Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all
the various forms of the FP feature names, so that it won't miss cases
where it should have set `HW_FP` to feed into feature test macros.

That in turn caused an ordering problem when handling `-mcpu=foo+bar`
together with `-mfpu=something_that_turns_off_bar`. To fix that, I've
arranged that the `+bar` suffixes on the end of `-mcpu` and `-march`
cause feature names to be put into a separate vector which is
concatenated after the output of `getFPUFeatures`.

Another side effect of all this is to fix a bug where `clang -target
armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even
though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was
because `HW_FP` was being set to a value including only the `FPARMV8`
bit, but that feature test macro was testing only the `VFP4FPU` bit.
Now `HW_FP` ends up with all the bits set, so it gives the right
answer.

Changes to tests included in this patch:

* `arm-target-features.c`: I had to change basically all the expected
  results. (The Cortex-M4 test in there should function as a
  regression test for the accidental double-precision bug.)
* `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG`
  everywhere so that those tests are no longer sensitive to the order
  of cc1 feature options on the command line.
* `arm-acle-6.5.c`: been updated to expect the right answer to that
  FMA test.
* `Preprocessor/arm-target-features.c`: added a regression test for
  the `mfpu=softvfp` issue.

Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne

Reviewed By: ostannard

Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62998

llvm-svn: 362791
2019-06-07 12:42:54 +00:00
Pengfei Wang 30bcda86db [X86] -march=cooperlake (clang)
Support intel -march=cooperlake in clang

Patch by Shengchen Kan (skan)

Differential Revision: https://reviews.llvm.org/D62835

llvm-svn: 362781
2019-06-07 08:53:37 +00:00
Pengfei Wang 3a29f7c99c [X86] Add ENQCMD instructions
For more details about these instructions, please refer to the latest
ISE document:
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference.

Patch by Tianqing Wang (tianqing)

Differential Revision: https://reviews.llvm.org/D62282

llvm-svn: 362685
2019-06-06 08:28:42 +00:00
Pengfei Wang cc3629d545 [X86] Add VP2INTERSECT instructions
Support intel AVX512 VP2INTERSECT instructions in clang

Patch by Xiang Zhang (xiangzhangllvm)

Differential Revision: https://reviews.llvm.org/D62367

llvm-svn: 362196
2019-05-31 06:09:35 +00:00
John McCall 059b823e70 Fix the predefined exponent limit macros for the 16-bit IEEE format.
The magnitude range of normalized _Float16 is 2^-14 (~6e-5) to
(2-2^-10)*2^15 (65504).  You might think, then, that the code is
correct to defne FLT16_MIN_EXP and FLT16_MAX_EXP to be -14 and 15
respectively.  However, for some reason the C specification actually
specifies a bias for these macros:

C11 5.2.4.2.2:

  - minimum negative integer such that FLT_RADIX raised to one less than
    that power is a normalized floating-point number, e_min:
      FLT_MIN_EXP
      DBL_MIN_EXP
      LDBL_MIN_EXP

  - maximum integer such that FLT_RADIX raised to one less than that
    power is a representable finite floating-point number, e_max:
      FLT_MAX_EXP
      DBL_MAX_EXP
      LDBL_MAX_EXP

FLT16_MIN_EXP and FLT16_MAX_EXP should clearly be biased the same way,
and other compilers do in fact do so, as do our OpenCL headers for `half`.

Additionally, FLT16_MIN_10_EXP is just wrong.

llvm-svn: 362183
2019-05-31 01:21:36 +00:00
Eric Fiselier 586831b2b0 Make __has_builtin work with __builtin_LINE and friends.
The source location builtins are implemented as keywords, but
__has_builtin should still report true for them.

This patch also fixes a test failure on systemz where the alignment
of string literals is 2 not 1.

llvm-svn: 361920
2019-05-29 03:15:36 +00:00
Volodymyr Sapsai e32ff09685 [Preprocessor] Fix crash emitting note with framework location for "file not found" error.
A filename can be remapped with a header map to point to a framework
header and we can find the corresponding framework without the header.
But if the original filename doesn't have a remapped framework name,
we'll fail to find its location and will dereference a null pointer
during diagnostics emission.

Fix by tracking remappings better and emit the note only if a framework
is found before any of the remappings.

rdar://problem/48883447

Reviewers: arphaman, erik.pilkington, jkorous

Reviewed By: arphaman

Subscribers: dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D61707

llvm-svn: 361779
2019-05-27 19:15:30 +00:00
Thomas Lively eafe8ef6f2 [WebAssembly] Add multivalue and tail-call target features
Summary:
These features will both be implemented soon, so I thought I would
save time by adding the boilerplate for both of them at the same time.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62047

llvm-svn: 361516
2019-05-23 17:26:47 +00:00
Javed Absar 603a2bac05 [ARM][CMSE] Add commandline option and feature macro
Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces
-mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3.
A diagnostic is produced when the option is given on architectures
without support for Security Extensions.
Reviewed By: dmgreen, snidertm
Differential Revision: https://reviews.llvm.org/D59879

llvm-svn: 361261
2019-05-21 14:21:26 +00:00
Kristina Brooks bd97484241 Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"
This relands commit rL360833 which caused issues on Win32
bots due to path handling/normalization differences. Now
this uses `sys::path::filename` which should handle
additional edge cases on Win32.

Original commit:

"[Clang][PP] Add the __FILE_NAME__ builtin macro" 

This patch adds the __FILE_NAME__ macro that expands to the
last component of the path, similar to __FILE__ except with
a guarantee that only the last path component (without the
separator) will be rendered.

I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.

Differential Revision: https://reviews.llvm.org/D61756

llvm-svn: 360938
2019-05-16 21:13:49 +00:00
Craig Topper 20040db9a6 [X86] Stop implicitly enabling avx512vl when avx512bf16 is enabled.
Previously we were doing this so that the 256 bit selectw builtin could be used in the implementation of the 512->256 bit conversion intrinsic.

After this commit we now use a masked convert builtin that will emit the intrinsic call and the 256-bit select from custom code in CGBuiltin. Then the header only needs to call that one intrinsic.

llvm-svn: 360924
2019-05-16 18:28:17 +00:00
Xing Xue 6dc363ecc1 Add AIX Version Macros
Summary:
- This patch checks the AIX version and defines the appropriate macros.
- Follow up to a comment on D59048.

Author: andusy

Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue

Reviewed By: sfertile

Subscribers: jsji, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61530

llvm-svn: 360900
2019-05-16 14:22:37 +00:00
Kristina Brooks 9d65624bf6 Revert r360833 until I can work out the issue with Win32 bots
This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro."

The tests are failing on Windows bots, reverting the patchset until I can
work out why.

llvm-svn: 360842
2019-05-16 03:30:08 +00:00
Kristina Brooks 3acc1d1be3 [Clang][PP] Add the __FILE_NAME__ builtin macro.
This patch adds the `__FILE_NAME__` macro that expands to the
last component of the path, similar to `__FILE__` except with
a guarantee that only the last path component (without the
separator) will be rendered.

I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.

Differential Revision: https://reviews.llvm.org/D61756

llvm-svn: 360833
2019-05-16 00:52:41 +00:00