Commit Graph

1024 Commits

Author SHA1 Message Date
Abderrazek Zaafrani ce8746d178 [AArch64] Add ARMv8.2-A FP16 scalar intrinsics
https://reviews.llvm.org/D41792

llvm-svn: 323006
2018-01-19 23:11:18 +00:00
Craig Topper 919264371b [X86][Sema] Range check the constant argument for the vpshld/vpshrd builtins to ensure it fits in 8-bits.
llvm-svn: 322247
2018-01-11 01:38:02 +00:00
Craig Topper 8e63fc70be [X86][Sema] Remove constant range checks on on builtins that take a char.
The constant is already reduced to 8-bits by the time we get here and the checks were just ensuring that it was 8 bits. Thus I don't think there's anyway for them to fail.

llvm-svn: 322244
2018-01-11 01:37:57 +00:00
Craig Topper 170de4b4ba [X86] Allow _mm_prefetch (both the header implementation and the builtin) to accept bit 2 which is supposed to indicate the prefetched addresses will be written to
Add the appropriate _MM_HINT_ET0/ET1 defines to match gcc.

llvm-svn: 321325
2017-12-21 23:50:22 +00:00
Adrian Prantl f3b3ccda59 Silence a bunch of implicit fallthrough warnings
llvm-svn: 321115
2017-12-19 22:06:11 +00:00
Richard Smith c70f1d63f8 [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.

All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.

llvm-svn: 320707
2017-12-14 15:16:18 +00:00
Richard Smith a5370fb82c Unify implementation of our two different flavours of -Wtautological-compare,
and fold together into a single function.

In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.

This re-commits r320122 and r320124, minus two changes:

 * Comparisons between a constant and a non-constant expression of enumeration
   type never warn, not even if the constant is out of range. We should be
   warning about the creation of such a constant, not about its use.

 * We do not use more precise bit-widths for comparisons against bit-fields.
   The more precise diagnostics probably are the right thing, but we should
   consider moving them under their own warning flag.

Other than the refactoring, this patch should only change the behavior for the
buggy cases (where the warnings didn't take into account that promotion from
signed to unsigned can leave a range of inaccessible values in the middle of
the promoted type).

llvm-svn: 320211
2017-12-08 22:57:11 +00:00
Hans Wennborg 5791ce77ba Revert "Unify implementation of our two different flavours of -Wtautological-compare."
> Unify implementation of our two different flavours of -Wtautological-compare.
>
> In so doing, fix a handful of remaining bugs where we would report false
> positives or false negatives if we promote a signed value to an unsigned type
> for the comparison.

This caused a new warning in Chromium:

../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
  DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
         ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 64.

I thought we didn't use to warn (with out-of-range-compare) when comparing
against the boundaries of a type?

llvm-svn: 320162
2017-12-08 16:54:08 +00:00
Hans Wennborg 5bb88e0f9e Revert r320124 "Fold together the in-range and out-of-range portions of -Wtautological-compare."
This broke Chromium:

../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
  DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
         ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 63.

Did this use to fall under the "in-range" case before? I thought we
didn't use to warn when comparing against the boundaries of a type.

llvm-svn: 320133
2017-12-08 05:19:12 +00:00
Richard Smith 6a7513e2cd Fold together the in-range and out-of-range portions of -Wtautological-compare.
llvm-svn: 320124
2017-12-08 01:00:27 +00:00
Richard Smith bf0ad43503 Unify implementation of our two different flavours of -Wtautological-compare.
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.

llvm-svn: 320122
2017-12-08 00:45:25 +00:00
Sjoerd Meijer 293da70b83 [ARM] ACLE parallel arithmetic and DSP style multiplications
This is a follow up of r302131, in which we forgot to add SemaChecking
tests. Adding these tests revealed two problems which have been fixed:
- added missing intrinsic __qdbl,
- properly range checking ssat16 and usat16.

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

llvm-svn: 320019
2017-12-07 09:54:39 +00:00
Roger Ferrer Ibanez d80d6c5a56 Ignore pointers to incomplete types when diagnosing misaligned addresses
This is a fix for PR35509 in which we crash because we attempt to compute the
alignment of an incomplete type.

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

llvm-svn: 320017
2017-12-07 09:23:50 +00:00
Richard Smith 692f66ab62 Delete special-case "out-of-range" handling for bools, and just use the normal
codepath plus the new "minimum / maximum value of type" diagnostic to get the
same effect.

Move the warning for an in-range but tautological comparison of a constant (0
or 1) against a bool out of -Wtautological-constant-out-of-range-compare into
the more-appropriate -Wtautological-constant-compare.

llvm-svn: 319942
2017-12-06 19:23:19 +00:00
Richard Smith 371e9e8a28 Fix a bunch of wrong "tautological unsigned enum compare" diagnostics in C++.
An enumeration with a fixed underlying type can have any value in its
underlying type, not just those spanned by the values of its enumerators.

llvm-svn: 319875
2017-12-06 03:00:51 +00:00
Aaron Ballman d1f6dcd1f5 Perform a bounds check on a function's argument list before accessing any index value specified by an 'argument_with_type_tag' attribute. Fixes PR28520.
Patch by Matt Davis.

llvm-svn: 319383
2017-11-29 23:10:14 +00:00
Hans Wennborg 9541975071 Revert r318556 "Loosen -Wempty-body warning"
It seems this somehow made -Wempty-body fire in some macro cases where
it didn't before, e.g.

  ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5):  error: if statement has empty body [-Werror,-Wempty-body]
      ff_dlog(NULL, "new table index=%d size=%d\n", table_index, table_size);
      ^
  ../../third_party/ffmpeg\libavutil/internal.h(276,80):  note: expanded from macro 'ff_dlog'
  #   define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0)
                                                                                 ^
  ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5):  note: put the
  semicolon on a separate line to silence this warning

Reverting until this can be figured out.

> Do not show it when `if` or `else` come from macros.
> E.g.,
>
>     #define USED(A) if (A); else
>     #define SOME_IF(A) if (A)
>
>     void test() {
>       // No warnings are shown in those cases now.
>       USED(0);
>       SOME_IF(0);
>     }
>
> Patch by Ilya Biryukov!
>
> Differential Revision: https://reviews.llvm.org/D40185

llvm-svn: 318665
2017-11-20 17:38:16 +00:00
Reid Kleckner c0a81071d3 Loosen -Wempty-body warning
Do not show it when `if` or `else` come from macros.
E.g.,

    #define USED(A) if (A); else
    #define SOME_IF(A) if (A)

    void test() {
      // No warnings are shown in those cases now.
      USED(0);
      SOME_IF(0);
    }

Patch by Ilya Biryukov!

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

llvm-svn: 318556
2017-11-17 21:33:28 +00:00
Alex Lorenz 42a97a94ca [ObjC][ARC] Honor noescape attribute for -Warc-retain-cycles
rdar://35409566

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

llvm-svn: 318552
2017-11-17 20:44:25 +00:00
Eugene Zelenko 11a7ef8559 [AST, Sema] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 318341
2017-11-15 22:00:04 +00:00
Craig Topper 23a302256a [X86] Add masked vcvtps2ph builtins to CheckX86BuiltinFunctionCall.
This ensures that only immediates that fit in 8-bits are used. This matches what we do for the unmasked versions.

llvm-svn: 317664
2017-11-08 04:54:26 +00:00
Roman Lebedev ca1aaacc32 [Sema] Fixes for enum handling for tautological comparison diagnostics
Summary:
As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should
be used when checking for the tautological comparison, unlike C++, where the enumerator
values define the value range. So if not in CPlusPlus mode, use the enum underlying type.

Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison:
```
enum A { A_a = 0 };
if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
return 0;
```
This affects both the C and C++, but after the first fix, only C++ code was affected.
That was also fixed, while preserving (i think?) the proper diagnostic output.

And while there, attempt to enhance the test coverage.
Yes, some tests got moved around, sorry about that :)

Fixes PR35009

Reviewers: aaron.ballman, rsmith, rjmccall

Reviewed By: aaron.ballman

Subscribers: Rakete1111, efriedma, materi, cfe-commits

Tags: #clang

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

llvm-svn: 316268
2017-10-21 16:44:03 +00:00
Saleem Abdulrasool a01ed93e8c Sema: use new `getNS{,U}IntegerType` for NS{,U}Integer
Use the new helper methods to get the underlying type for NSUInteger,
NSInteger types.  This avoids spreading the knowledge of the underlying
types in various sites.  For non-LLP64 targets, this has no change.

llvm-svn: 316013
2017-10-17 17:39:32 +00:00
Roman Lebedev 6de129e710 [Sema] Re-land: Diagnose tautological comparison with type's min/max values
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.

Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak

Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565

Reviewers: rjmccall, rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: rtrieu, jroelofs, cfe-commits

Tags: #clang

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

llvm-svn: 315875
2017-10-15 20:13:17 +00:00
Alexander Richardson 6d989436d0 Convert clang::LangAS to a strongly typed enum
Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.

I found the following errors while writing this patch:

- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
  space to  TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
  clang AST address space instead of the target address space.
  However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
  LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
  TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
  to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
  llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
  space. As this is exposed to C I have kept the current behaviour and
  added a comment stating that it is probably not correct.

Other than this the patch should not cause any functional changes.

Reviewers: yaxunl, pcc, bader

Reviewed By: yaxunl, bader

Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits

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

llvm-svn: 315871
2017-10-15 18:48:14 +00:00
Yaxun Liu b7318e02c1 [OpenCL] Add LangAS::opencl_private to represent private address space in AST
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:

Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.

This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:

automatic variables without address space qualifier

function parameter

pointee type without address space qualifier (OpenCL 1.2 and below)

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

llvm-svn: 315668
2017-10-13 03:37:48 +00:00
Roman Lebedev 6f405dbe5c Revert "[Sema] Diagnose tautological comparison with type's min/max values"
This reverts r315614,r315615,r315621,r315622
Breaks http://bb9.pgr.jp/#/builders/20/builds/59

/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
    if (max_sec > Lim::max()) return false;
        ~~~~~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare]
    if (sec < Lim::min() || sec > Lim::max())   return false;
        ~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
    if (sec < Lim::min() || sec > Lim::max())   return false;
                            ~~~ ^ ~~~~~~~~~~
3 errors generated.
--

I'm not yet sure what is the proper fix.

llvm-svn: 315631
2017-10-12 22:03:20 +00:00
Davide Italiano fe54b50583 [SemaChecking] Suppress a GCC warning. NFCI.
llvm-svn: 315621
2017-10-12 21:08:29 +00:00
Roman Lebedev bd1fc22043 [Sema] Diagnose tautological comparison with type's min/max values
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak

Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565

Reviewers: rjmccall, rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: rtrieu, jroelofs, cfe-commits

Tags: #clang

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

llvm-svn: 315614
2017-10-12 20:16:51 +00:00
Nico Weber b688d131f0 Consolidate std::move() detection code. No behavior change.
llvm-svn: 314427
2017-09-28 16:16:39 +00:00
Saleem Abdulrasool 3450aa7257 Sema: rename SemaBuiltinVAStart to SemaBuiltinVAStartMicrosoft
This function is used to perform semantic analysis on Microsoft style
`__va_start`.  Rename it to make this more explicit.  `__va_start` is
marked as `ALL_MS_LANGUAGES`, and requires Microsoft compatibility.
Other GNU targets will use `__builtin_va_start` instead.  NFC.

Addresses post-commit review comments from David Majnemer.

llvm-svn: 314241
2017-09-26 20:12:04 +00:00
Saleem Abdulrasool 448e8ad943 Sema: Windows/ARM __va_start is not const correct
The `__va_start` intrinsic for Windows ARM does not account for const
correctness when performing a check.  All local qualifiers are ignored
when validating the invocation.  This was exposed by building the swift
stdlib against the Windows 10586 SDK for ARM.  Simply expand out the
check for the two parameters and ignore the qualifiers for the check.

llvm-svn: 314226
2017-09-26 17:44:10 +00:00
Alexander Shaposhnikov 1788a9b71c [clang] Fix printf fixit for objc specific types
For the triple thumbv7-apple-ios8.0.0 ssize_t is long and size_t is unsigned long,
while NSInteger is int and NSUinteger is unsigned int. Following 
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
Clang catches it and insert a cast to long, for example
 printf("%zd", getNSInteger())
will be replaced with 
 printf("%zd", (long)getNSInteger())
but since the underlying type of ssize_t is long the specifier "%zd" is not getting replaced.
This diff changes this behavior to enable replacing the specifier "%zd" with the correct one.

Differential revision: https://reviews.llvm.org/D38159

Test plan: make check-all

llvm-svn: 314011
2017-09-22 18:36:06 +00:00
Erich Keane 69dbbb0bca Suppress Wsign-conversion for enums with matching underlying type
As reported here: https://bugs.llvm.org/show_bug.cgi?id=34692

A non-defined enum with a backing type was always defaulting to
being treated as a signed type. IN the case where it IS defined,
the signed-ness of the actual items is used.

This patch uses the underlying type's signed-ness in the non-defined
case to test signed-comparision.

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

llvm-svn: 313907
2017-09-21 19:58:55 +00:00
Roman Lebedev 30d2608637 Replace r313747, don't always warn on enums, rework testcases.
As Aaron Ballman has pointed out, that is not really correct.
So the key problem there is the invalidity of the testcase.

Revert r313747, and rework testcase in such a way, so these
details (platform-specific default enum sigdness) are
accounted for.

Also, add a C++-specific testcase.

llvm-svn: 313756
2017-09-20 13:50:01 +00:00
Roman Lebedev b513ebfc0f [Sema] CheckTautologicalComparisonWithZero(): always complain about enums
Hopefully fixes test-clang-msc-x64-on-i686-linux-RA build.

The underlying problem is that the enum is signed there.
Yet still, it is invalid for it to contain negative values,
so the comparison is always tautological in this case.

No differential, but related to https://reviews.llvm.org/D37629

llvm-svn: 313747
2017-09-20 10:15:27 +00:00
Roman Lebedev b0f0a1ea03 [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare
Recommit. Original commit was reverted because buildbots broke.
The error was only reproducible in the build with assertions.
The problem was that the diagnostic expected true/false as
bool, while it was provided as string "true"/"false".

Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?

Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper

Reviewed By: aaron.ballman

Subscribers: jroelofs, cfe-commits

Tags: #clang

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

llvm-svn: 313745
2017-09-20 09:54:47 +00:00
Roman Lebedev 918eaf9585 Revert "[Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare"
This reverts commit r313677.

Buildbots fail with assertion failure
Failing Tests (7):
    Clang :: Analysis/null-deref-ps.c
    Clang :: CodeGen/enum.c
    Clang :: Sema/compare.c
    Clang :: Sema/outof-range-constant-compare.c
    Clang :: Sema/tautological-unsigned-enum-zero-compare.c
    Clang :: Sema/tautological-unsigned-zero-compare.c
    Clang :: SemaCXX/compare.cpp

llvm-svn: 313683
2017-09-19 21:40:41 +00:00
Roman Lebedev c9c9748d99 [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare
Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?

Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper

Reviewed By: aaron.ballman

Subscribers: jroelofs, cfe-commits

Tags: #clang

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

llvm-svn: 313677
2017-09-19 21:11:35 +00:00
Roman Lebedev 6aa34aadd1 [Sema] -Wtautological-compare: handle comparison of unsigned with 0S.
Summary:
This is a first half(?) of a fix for the following bug:
https://bugs.llvm.org/show_bug.cgi?id=34147 (gcc -Wtype-limits)

GCC's -Wtype-limits does warn on comparison of unsigned value
with signed zero (as in, with 0), but clang only warns if the
zero is unsigned (i.e. 0U).

Also, be careful not to double-warn, or falsely warn on
comparison of signed/fp variable and signed 0.

Yes, all these testcases are needed.

Testing: $ ninja check-clang-sema check-clang-semacxx
Also, no new warnings for clang stage-2 build.

Reviewers: rjmccall, rsmith, aaron.ballman

Reviewed By: rjmccall

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 312750
2017-09-07 22:14:25 +00:00
Reid Kleckner 30701edf76 [ms] Implement the __annotation intrinsic
llvm-svn: 312572
2017-09-05 20:27:35 +00:00
Yaxun Liu 30d652a447 [OpenCL] Support variable memory scope in atomic builtins
Differential Revision: https://reviews.llvm.org/D36580

llvm-svn: 310924
2017-08-15 16:02:49 +00:00
Craig Topper 699ae0c173 [X86] Implement __builtin_cpu_is
This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc.

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

llvm-svn: 310657
2017-08-10 20:28:30 +00:00
Joey Gouly 922ca2345d [OpenCL] Minor refactoring to reduce copy/pasted code
Set the type of TheCall inside SemaBuiltinReserveRWPipe to reduce
duplicated code.

llvm-svn: 310477
2017-08-09 14:52:47 +00:00
Tim Northover 0241637c0e Sema: disable implicit conversion from _Complex to real types in C++.
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.

The one exception is bool, which actually compares both real and imaginary
parts and so is safe.

llvm-svn: 310427
2017-08-08 23:18:05 +00:00
Yaxun Liu 39195062c2 Add OpenCL 2.0 atomic builtin functions as Clang builtin
OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instructions.

Clang supports translating Clang atomic builtin functions to LLVM atomic
instructions. However it currently does not support synchronization scope
of LLVM atomic instructions. Without this, users have to use LLVM assembly
code to implement OpenCL atomic builtin functions.

This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin
functions, which supports generating LLVM atomic instructions with
synchronization scope operand.

Currently only constant memory scope argument is supported. Support of
non-constant memory scope argument will be added later.

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

llvm-svn: 310082
2017-08-04 18:16:31 +00:00
Joey Gouly fa76b49cef [OpenCL] Add missing subgroup builtins
This adds get_kernel_max_sub_group_size_for_ndrange and
get_kernel_sub_group_count_for_ndrange.

llvm-svn: 309678
2017-08-01 13:27:09 +00:00
Joey Gouly 84ae3364df [OpenCL] Add extension Sema check for subgroup builtins
Check the subgroup extension is enabled, before doing other Sema checks.

llvm-svn: 309567
2017-07-31 15:15:59 +00:00
Martin Storsjo 022e782e75 [AArch64] Add support for __builtin_ms_va_list on aarch64
Move builtins from the x86 specific scope into the global
scope. Their use is still limited to x86_64 and aarch64 though.

This allows wine on aarch64 to properly handle variadic functions.

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

llvm-svn: 308218
2017-07-17 20:49:45 +00:00
Ulrich Weigand cac24ab04c [SystemZ] Add support for IBM z14 processor (1/3)
This patch series adds support for the IBM z14 processor.  This part includes:
- Basic support for the new processor and its features.
- Support for low-level builtins mapped to new LLVM intrinsics.

Support for the -fzvector extension to vector float and the new
high-level vector intrinsics is provided by separate patches.

llvm-svn: 308197
2017-07-17 17:45:57 +00:00