Commit Graph

2834 Commits

Author SHA1 Message Date
Erich Keane 5f0903e9be Reland Implement _ExtInt as an extended int type specifier.
I fixed the LLDB issue, so re-applying the patch.

This reverts commit a4b88c0449.
2020-04-17 10:45:48 -07:00
Sterling Augustine a4b88c0449 Revert "Implement _ExtInt as an extended int type specifier."
This reverts commit 61ba1481e2.

I'm reverting this because it breaks the lldb build with
incomplete switch coverage warnings. I would fix it forward,
but am not familiar enough with lldb to determine the correct
fix.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
2020-04-17 10:29:40 -07:00
Erich Keane 61ba1481e2 Implement _ExtInt as an extended int type specifier.
Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly interesting or useful
on most hardware, so much so that no language in Clang has been
motivated to expose it before.

However, in the case of FPGA hardware normal integer types where the
full bitwidth isn't used, is extremely wasteful and has severe
performance/space concerns.  Because of this, Intel has introduced this
functionality in the High Level Synthesis compiler[0]
under the name "Arbitrary Precision Integer" (ap_int for short). This
has been extremely useful and effective for our users, permitting them
to optimize their storage and operation space on an architecture where
both can be extremely expensive.

We are proposing upstreaming a more palatable version of this to the
community, in the form of this proposal and accompanying patch.  We are
proposing the syntax _ExtInt(N).  We intend to propose this to the WG14
committee[1], and the underscore-capital seems like the active direction
for a WG14 paper's acceptance.  An alternative that Richard Smith
suggested on the initial review was __int(N), however we believe that
is much less acceptable by WG14.  We considered _Int, however _Int is
used as an identifier in libstdc++ and there is no good way to fall
back to an identifier (since _Int(5) is indistinguishable from an
unnamed initializer of a template type named _Int).

[0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html)
[1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf

Differential Revision: https://reviews.llvm.org/D73967
2020-04-17 07:10:57 -07:00
Bevin Hansson fd7a341861 [Fixed Point] Move the compassign LHS type correction a bit further down. NFCI.
Summary:
We can simplify the LHSTy correction for
fixed-point compassign by moving it below
the point where we know we have a compound
assignment.

Also, we shouldn't look at the LHS and RHS
separately; look at the computation result
type instead.

Looking at the LHS and RHS is also wrong
for compassigns with fixed and floating
point (though this does not work upstream
yet).

Reviewers: leonardchan

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78294
2020-04-17 10:09:02 +02:00
Melanie Blower 8812b0cc5c [NFC] Rename Sema.FPFeatures to CurFPFeatures and accessor to getCurFPFeatures 2020-04-16 08:50:14 -07:00
Melanie Blower 2ba4e3a459 Move BinaryOperators.FPOptions to trailing storage
Reviewers: rjmccall

Differential Revision: https://reviews.llvm.org/D76384
2020-04-15 12:57:31 -07:00
Richard Smith bab6df86ae Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.
Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.

With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.

This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.

This fixes a few bugs and issues:
 * PR38490: we now support reading from GUID objects returned from
   __uuidof during constant evaluation.
 * Our Itanium mangling for a non-instantiation-dependent template
   argument involving __uuidof no longer depends on which CXXUuidofExpr
   template argument we happened to see first.
 * We now predeclare ::_GUID, and permit use of __uuidof without
   any header inclusion, better matching MSVC's behavior. We do not
   predefine ::__s_GUID, though; that seems like a step too far.
 * Our IR representation for GUID constants now uses the correct IR type
   wherever possible. We will still fall back to using the
      {i32, i16, i16, [8 x i8]}
   layout if a definition of struct _GUID is not available. This is not
   ideal: in principle the two layouts could have different padding.

Reviewers: rnk, jdoerfert

Subscribers: arphaman, cfe-commits, aeubanks

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78171
2020-04-15 12:20:42 -07:00
Reid Kleckner 55efb68c19 [MS] Mark vbase dtors used when marking dtor used
In the MS C++ ABI, the complete destructor variant for a class with
virtual bases is emitted whereever it is needed, instead of directly
alongside the base destructor variant. The complete destructor calls the
base destructor of the current class and the base destructors of each
virtual base. In order for this to work reliably, translation units that
use the destructor of a class also need to mark destructors of virtual
bases of that class used.

Fixes PR38521

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D77081
2020-04-09 14:19:36 -07:00
Serge Pavlov c7ff5b38f2 [FPEnv] Use single enum to represent rounding mode
Now compiler defines 5 sets of constants to represent rounding mode.
These are:

1. `llvm::APFloatBase::roundingMode`. It specifies all 5 rounding modes
defined by IEEE-754 and is used in `APFloat` implementation.

2. `clang::LangOptions::FPRoundingModeKind`. It specifies 4 of 5 IEEE-754
rounding modes and a special value for dynamic rounding mode. It is used
in clang frontend.

3. `llvm::fp::RoundingMode`. Defines the same values as
`clang::LangOptions::FPRoundingModeKind` but in different order. It is
used to specify rounding mode in in IR and functions that operate IR.

4. Rounding mode representation used by `FLT_ROUNDS` (C11, 5.2.4.2.2p7).
Besides constants for rounding mode it also uses a special value to
indicate error. It is convenient to use in intrinsic functions, as it
represents platform-independent representation for rounding mode. In this
role it is used in some pending patches.

5. Values like `FE_DOWNWARD` and other, which specify rounding mode in
library calls `fesetround` and `fegetround`. Often they represent bits
of some control register, so they are target-dependent. The same names
(not values) and a special name `FE_DYNAMIC` are used in
`#pragma STDC FENV_ROUND`.

The first 4 sets of constants are target independent and could have the
same numerical representation. It would simplify conversion between the
representations. Also now `clang::LangOptions::FPRoundingModeKind` and
`llvm::fp::RoundingMode` do not contain the value for IEEE-754 rounding
direction `roundTiesToAway`, although it is supported natively on
some targets.

This change defines all the rounding mode type via one `llvm::RoundingMode`,
which also contains rounding mode for IEEE rounding direction `roundTiesToAway`.

Differential Revision: https://reviews.llvm.org/D77379
2020-04-09 13:26:47 +07:00
Bevin Hansson 313461f6d8 [CodeGen] Emit IR for compound assignment with fixed-point operands.
Reviewers: rjmccall, leonardchan

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73184
2020-04-08 14:33:04 +02:00
Alexey Bataev be99c61588 [OPENMP50]Codegen for iterator construct.
Implemented codegen for the iterator expression in the depend clauses.
Iterator construct is emitted the following way:
iterator(cnt1, cnt2, ...), in : <dep>

<TotalNumDeps> = <cnt1_size> * <cnt2_size> * ...;
kmp_depend_t deps[<TotalNumDeps>];
deps_counter = 0;
for (cnt1) {
  for (cnt2) {
    ...
    deps[deps_counter].base_addr = &<dep>;
    deps[deps_counter].size = sizeof(<dep>);
    deps[deps_counter].flags = in;
    deps_counter += 1;
    ...
  }
}

For depobj construct the codegen is very similar, but the memory is
allocated dynamically and added extra first item reserved for internal use.
2020-04-07 15:26:00 -04:00
Aaron Ballman 86b5eabfea Allow parameter names to be elided in a function definition in C.
WG14 has adopted N2480 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2480.pdf)
into C2x at the meetings last week, allowing parameter names of a function
definition to be elided. This patch relaxes the error so that C++ and C2x do not
diagnose this situation, and modes before C2x will allow it as an extension.

This also adds the same feature to ObjC blocks under the assumption that ObjC
wishes to follow the C standard in this regard.
2020-04-07 14:43:38 -04:00
Richard Smith c56975e299 Fix template instantiation of a non-dependent call to an inherited
constructor with default arguments.

We used to try to rebuild the call as a call to the faked-up inherited
constructor, which is only a placeholder and lacks (for example) default
arguments. Instead, build the call by reference to the original
constructor.

In passing, add a note to say where a call that recursively uses a
default argument from within itself occurs. This is usually pretty
obvious, but still at least somewhat useful, and would have saved
significant debugging time for this particular bug.
2020-04-06 19:20:30 -07:00
Johannes Doerfert ceed44adfd [OpenMP][NFC] Remove unnecessary argument 2020-04-04 11:34:58 -05:00
Alexey Bataev 13a1504ffb [OPENMP50]Add initial support for OpenMP 5.0 iterator.
Added basic parsing/semantic analysis/(de)serialization support for
iterator expression introduced in OpenMP 5.0.
2020-04-02 08:28:15 -04:00
Alexey Bataev c028472fa1 Revert "[OPENMP50]Add initial support for OpenMP 5.0 iterator."
This reverts commit f08df464ae to fix the
bug with serialization support for iterator expression.
2020-04-01 14:54:45 -04:00
Alexey Bataev f08df464ae [OPENMP50]Add initial support for OpenMP 5.0 iterator.
Added basic parsing/semantic analysis/(de)serialization support for
iterator expression introduced in OpenMP 5.0.
2020-04-01 12:53:55 -04:00
Alexey Bataev e094dd5adc [OPENMP50]Fix size calculation for array shaping expression in the
codegen.

Need to include the size of the pointee type when trying to calculate
the total size of the array shaping expression.
2020-03-31 18:45:21 -04:00
Alexey Bataev a4f74f377b [OPENMP50]Do not imply lvalue as base expression in array shaping
expression.

We should not assume that the base expression in the array shaping
operation is an lvalue of some form, it may be an rvalue.
2020-03-30 17:07:08 -04:00
Alexey Bataev 7ac9efb0c3 [OPENMP50]Add basic support for array-shaping operation.
Summary:
Added basic representation and parsing/sema handling of array-shaping
operations. Array shaping expression is an expression of form ([s0]..[sn])base,
where s0, ..., sn must be a positive integer, base - a pointer. This
expression is a kind of cast operation that converts pointer expression
into an array-like kind of expression.

Reviewers: rjmccall, rsmith, jdoerfert

Subscribers: guansong, arphaman, cfe-commits, caomhin, kkwli0

Tags: #clang

Differential Revision: https://reviews.llvm.org/D74144
2020-03-30 09:18:24 -04:00
Johannes Doerfert befb4be3a8 [OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG")
This is the second part loosely extracted from D71179 and cleaned up.

This patch provides semantic analysis support for `omp begin/end declare
variant`, mostly as defined in OpenMP technical report 8 (TR8) [0].
The sema handling makes code generation obsolete as we generate "the
right" calls that can just be handled as usual. This handling also
applies to the existing, albeit problematic, `omp declare variant
support`. As a consequence a lot of unneeded code generation and
complexity is removed.

A major purpose of this patch is to provide proper `math.h`/`cmath`
support for OpenMP target offloading. See PR42061, PR42798, PR42799. The
current code was developed with this feature in mind, see [1].

The logic is as follows:

If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)`
but not the corresponding `end declare variant`, and we find a function
definition we will:
  1) Create a function declaration for the definition we were about to generate.
  2) Create a function definition but with a mangled name (according to
     `<SELECTOR>`).
  3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same
     one used already for `omp declare variant`, using and the mangled
     function definition as specialization for the context defined by
     `<SELECTOR>`.

When a call is created we inspect it. If the target has an
`OMPDeclareVariantAttr` attribute we try to specialize the call. To this
end, all variants are checked, the best applicable one is picked and a
new call to the specialization is created. The new call is used instead
of the original one to the base function. To keep the AST printing and
tooling possible we utilize the PseudoObjectExpr. The original call is
the syntactic expression, the specialized call is the semantic
expression.

[0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf
[1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN

Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman

Subscribers: bollu, guansong, openmp-commits, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D75779
2020-03-27 02:30:58 -05:00
Haojian Wu 62dea6e9be Revert "[AST] Build recovery expressions by default for C++."
This reverts commit 0788acbccb.
This reverts commit c2d7a1f79cedfc9fcb518596aa839da4de0adb69:  Revert "[clangd] Add test for FindTarget+RecoveryExpr (which already works). NFC"

It causes a crash on invalid code:

class X {
  decltype(unresolved()) foo;
};
constexpr int s = sizeof(X);
2020-03-26 16:25:32 +01:00
Erich Keane 044c51d8d4 Fix vector type scalar checking when the scalar operand is dependent
As reported in PR45298 and PR45299, vector_size type checking would
crash when done in a situation where the scalar is dependent, such as
a member of the current instantiation.

This is because the scalar checking ensures that you can implicitly
convert a value to a vector-type as long as it doesn't require
truncation. It does this by using the constant evaluator to get the
value as a float. Unfortunately, if the scalar is dependent (such as a
member of the current instantiation), we would hit the assert in the
evaluator.

This patch suppresses the truncation- of-value check in the first phase
of translation. All values are properly errored upon instantiation. This
has one minor regression, in that previously in a non-asserts build,

template<typename T>
struct S {
  float4 f(float4 f) {
    return k + f;
  }
  static constexpr k = 1.1; // causes a truncation on conversion.
};

would error immediately. Because 'k' is value dependent (as a
member-of-the-current-instantiation), this would still be evaluatable
(despite normally asserting).  Due to this patch, this diagnostic is
delayed until instantiation time.
2020-03-25 11:38:58 -07:00
Erich Keane b5a034e771 [SYCL] Implement __builtin_unique_stable_name.
In order to support non-user-named kernels, SYCL needs some way in the
integration headers to name the kernel object themselves. Initially, the
design considered just RTTI naming of the lambdas, this results in a
quite unstable situation in light of some device/host macros.
Additionally, this ends up needing to use RTTI, which is a burden on the
implementation and typically unsupported.

Instead, we've introduced a builtin, __builtin_unique_stable_name, which
takes a type or expression, and results in a constexpr constant
character array that uniquely represents the type (or type of the
expression) being passed to it.

The implementation accomplishes that simply by using a slightly modified
version of the Itanium Mangling. The one exception is when mangling
lambdas, instead of appending the index of the lambda in the function,
it appends the macro-expansion back-trace of the lambda itself in the
form LINE->COL[~LINE->COL...].

Differential Revision: https://reviews.llvm.org/D76620
2020-03-25 07:01:50 -07:00
Richard Sandiford 578fb2501a [Sema][SVE] Allow ?: to select between SVE types in C
When compiling C, a ?: between two values of the same SVE type
currently gives an error such as:

  incompatible operand types ('svint8_t' (aka '__SVInt8_t') and 'svint8_t')

It's supposed to be valid to select between (cv-qualified versions of)
the same SVE type, so this patch adds that case.

These expressions already work for C++ and are tested by
SemaCXX/sizeless-1.cpp.

Differential Revision: https://reviews.llvm.org/D76693
2020-03-25 10:31:09 +00:00
Haojian Wu 0788acbccb [AST] Build recovery expressions by default for C++.
Update the existing tests.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76696
2020-03-25 09:00:48 +01:00
Momchil Velikov 080d046c91 [ARM][CMSE] Implement CMSE attributes
This patch adds CMSE attributes `cmse_nonsecure_call` and
`cmse_nonsecure_entry`.  As usual, specification is available here:
https://developer.arm.com/docs/ecm0359818/latest

Patch by Javed Absar, Bradley Smith, David Green, Momchil Velikov,
possibly others.

Differential Revision: https://reviews.llvm.org/D71129
2020-03-24 10:21:26 +00:00
Haojian Wu 733edf9750 [AST] Add RecoveryExpr to retain expressions on semantic errors
Normally clang avoids creating expressions when it encounters semantic
errors, even if the parser knows which expression to produce.

This works well for the compiler. However, this is not ideal for
source-level tools that have to deal with broken code, e.g. clangd is
not able to provide navigation features even for names that compiler
knows how to resolve.

The new RecoveryExpr aims to capture the minimal set of information
useful for the tools that need to deal with incorrect code:

source range of the expression being dropped,
subexpressions of the expression.
We aim to make constructing RecoveryExprs as simple as possible to
ensure writing code to avoid dropping expressions is easy.

Producing RecoveryExprs can result in new code paths being taken in the
frontend. In particular, clang can produce some new diagnostics now and
we aim to suppress bogus ones based on Expr::containsErrors.

We deliberately produce RecoveryExprs only in the parser for now to
minimize the code affected by this patch. Producing RecoveryExprs in
Sema potentially allows to preserve more information (e.g. type of an
expression), but also results in more code being affected. E.g.
SFINAE checks will have to take presence of RecoveryExprs into account.

Initial implementation only works in C++ mode, as it relies on compiler
postponing diagnostics on dependent expressions. C and ObjC often do not
do this, so they require more work to make sure we do not produce too
many bogus diagnostics on the new expressions.

See documentation of RecoveryExpr for more details.

original patch from Ilya
This change is based on https://reviews.llvm.org/D61722

Reviewers: sammccall, rsmith

Reviewed By: sammccall, rsmith

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69330
2020-03-24 09:20:37 +01:00
Yaxun (Sam) Liu b670ab7b6b recommit 1b978ddba0 [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese
Differential Revision: https://reviews.llvm.org/D70172
2020-03-23 12:09:07 -04:00
Akira Hatanaka d35a454170 [CodeGen] Emit destructor calls to destruct non-trivial C struct objects
returned by function calls or loaded from volatile objects

rdar://problem/51867864

Differential Revision: https://reviews.llvm.org/D66094
2020-03-20 18:34:22 -07:00
Wyatt Childers be10b7e43a Use values cached in ConstantExprs for expression evaluation where
present.

No functionality change intended.

Differential Revision: https://reviews.llvm.org/D76438
2020-03-20 18:14:58 -07:00
Michael Liao a4edea29be Fix `-Wunused-variable` warning. NFC. 2020-03-20 09:31:58 -04:00
Tyker 180581cfcf [clang] Add support for consteval constructors
Summary:
Changes:
 - handle immediate invocations for constructors.
 - add tests

after this patch i believe the implementation of consteval is nearly standard compliant, but IR-gen still needs to be taught not to emit consteval declarations.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: wchilders

Differential Revision: https://reviews.llvm.org/D74007
2020-03-20 11:33:54 +01:00
Yaxun (Sam) Liu 62201763c5 Fix crash in check-mlir due to 08ab8c9af4 2020-03-18 21:50:00 -04:00
Yaxun (Sam) Liu 08ab8c9af4 [NFC] Add UsedDeclVisitor
Differential Revision: https://reviews.llvm.org/D76262
2020-03-17 12:12:40 -04:00
Richard Sandiford 94489f35a7 [Sema][SVE] Reject arithmetic on pointers to sizeless types
This patch completes a trio of changes related to arrays of
sizeless types.  It rejects various forms of arithmetic on
pointers to sizeless types, in the same way as for other
incomplete types.

Differential Revision: https://reviews.llvm.org/D76086
2020-03-17 11:35:20 +00:00
Richard Sandiford 010005f077 [Sema][SVE] Reject subscripts on pointers to sizeless types
clang currently accepts:

  __SVInt8_t &foo1(__SVInt8_t *x) { return *x; }
  __SVInt8_t &foo2(__SVInt8_t *x) { return x[1]; }

The first function is valid ACLE code and generates correct LLVM IR
(and assembly code).  But the second function is invalid for the
same reason that arrays of sizeless types are.  Trying to code-generate
the function leads to:

  llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a s
calable object"' failed.

Another problem is that:

  template<typename T>
  constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
  typedef int arr1[f((int *)0) - 1];
  typedef int arr2[f((__SVInt8_t *)0) - 1];

produces:

  a.cpp:2:48: warning: subtraction of pointers to type '__SVInt8_t' of zero size has undefined behavior [-Wpointer-arith]
  constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
					   ~~~~~ ^ ~
  a.cpp:4:18: note: in instantiation of function template specialization 'f<__SVInt8_t>' requested here
  typedef int arr2[f((__SVInt8_t *)0) - 1];

This patch reports an appropriate diagnostic instead.

Differential Revision: https://reviews.llvm.org/D76084
2020-03-17 11:24:57 +00:00
Haojian Wu 876bb86e26 [AST] Move dependence computations into a separate file
To group the code in one place, simplify it and make it easier to add
the containsErrors bit and find existing bugs.

Reviewers: sammccall

Reviewed By: sammccall

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73638
2020-03-17 09:22:31 +01:00
Haojian Wu 18c9766248 Revert "[AST] Move dependence computations into a separate file"
This reverts commit ddd20ed158.
The patch was landed by accident.
2020-03-16 16:49:38 +01:00
Ilya Biryukov ddd20ed158 [AST] Move dependence computations into a separate file
To group the code in one place, simplify it and make it easier to add
the containsErrors bit and find existing bugs.
2020-03-16 16:48:49 +01:00
Alexey Bataev b3998a0edb [OPENMP]Fix PR45047: Do not copy firstprivates in tasks twice.
Avoid copying of the orignal variable if it is going to be marked as
firstprivate in task regions. For taskloops, still need to copy the
non-trvially copyable variables to correctly construct them upon task
creation.
2020-03-13 18:04:16 -04:00
Akira Hatanaka 86bba6c641 [Sema] Use the canonical type in function isVector
This reapplies the following patch, which was reverted because it caused
neon CodeGen tests to fail:

https://reviews.llvm.org/rGa6150b48cea00ab31e9335cc73770327acc4cb3a

I've added checks to detect half precision neon vectors and avoid
promiting them to vectors of floats.

See the discussion here: https://reviews.llvm.org/rG825235c140e7

Original commit message:

This fixes an assertion in Sema::CreateBuiltinBinOp that fails when one
of the vector operand's element type is a typedef of __fp16.

rdar://problem/55983556
2020-03-13 13:08:48 -07:00
Richard Sandiford 994c071a1b [Sema][SVE] Reject arrays of sizeless types
The SVE ACLE doesn't allow arrays of sizeless types.  At the moment
clang accepts the TU:

  __SVInt8_t x[2];

but trying to code-generate it triggers the LLVM assertion:

  llvm/lib/IR/Type.cpp:588: static llvm::ArrayType* llvm::ArrayType::get(llvm::Type*, uint64_t): Assertion `isValidElementType(ElementType) && "Invalid type for array element!"' failed.

This patch reports an appropriate error instead.

The rules are slightly more restrictive than for general incomplete types.
For example:

  struct s;
  typedef struct s arr[2];

is valid as far as it goes, whereas arrays of sizeless types are
invalid in all contexts.  BuildArrayType therefore needs a specific
check for isSizelessType in addition to the usual handling of
incomplete types.

Differential Revision: https://reviews.llvm.org/D76082
2020-03-13 19:28:45 +00:00
Richard Sandiford 8c5c60a493 [Sema][SVE] Reject by-copy capture of sizeless types
Since fields can't have sizeless type, it also doesn't make sense
to capture sizeless types by value in lambda expressions.  This patch
makes sure that we diagnose that and that we use "sizeless type" rather
"incomplete type" in the associated message.  (Both are correct, but
"sizeless type" is more specific and hopefully more user-friendly.)

Differential Revision: https://reviews.llvm.org/D75738
2020-03-13 19:27:31 +00:00
Alexey Bataev 172f1460ae [OPENMP]Reduce number of captured global vars.
Try to reduce the number of global vars captured in the OpenMP regions
by capturing them only the regions, which mark them as not-shared.
2020-03-13 10:47:54 -04:00
Richard Sandiford 39969c7d3a [Sema][SVE] Reject sizeof and alignof for sizeless types
clang current accepts:

  void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; }
  void foo2(__SVInt8_t *x, __SVInt8_t *y) {
    memcpy(y, x, sizeof(__SVInt8_t));
  }

The first function is valid ACLE code and generates correct LLVM IR.
However, the second function is invalid ACLE code and generates a
zero-length memcpy.  The point of this patch is to reject the use
of sizeof in the second case instead.

There's no similar wrong-code bug for alignof.  However, the SVE ACLE
conservatively treats alignof in the same way as sizeof, just as the
C++ standard does for incomplete types.  The idea is that layout of
sizeless types is an implementation property and isn't defined at
the language level.

Implementation-wise, the patch adds a new CompleteTypeKind enum
that controls whether RequireCompleteType & friends accept sizeless
built-in types.  For now the default is to maintain the status quo
and accept sizeless types.  However, the end of the series will flip
the default and remove the Default enum value.

The patch also adds new ...CompleteSized... wrappers that callers can
use if they explicitly want to reject sizeless types.  The callers then
use diagnostics that have an extra 0/1 parameter to indicats whether
the type is sizeless or not.

The idea is to have three cases:

1. calls that explicitly reject sizeless types, with a tweaked diagnostic
   for the sizeless case

2. calls that explicitly allow sizeless types

3. normal/old-style calls that don't make an explicit choice either way

Once the default is flipped, the 3. calls will conservatively reject
sizeless types, using the same diagnostic as for other incomplete types.

Differential Revision: https://reviews.llvm.org/D75572
2020-03-12 17:06:53 +00:00
Richard Smith 5c845c1c50 PR45083: Mark statement expressions as being dependent if they appear in
a dependent context.

This matches the GCC behavior.

We track the enclosing template depth when determining whether a
statement expression is within a dependent context; there doesn't appear
to be any other reliable way to determine this.

We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
2020-03-10 14:45:04 -07:00
Akira Hatanaka 40568fec7e [CodeGen] Emit destructor calls to destruct compound literals
Fix a bug in IRGen where it wasn't destructing compound literals in C
that are ObjC pointer arrays or non-trivial structs. Also diagnose jumps
that enter or exit the lifetime of the compound literals.

rdar://problem/51867864

Differential Revision: https://reviews.llvm.org/D64464
2020-03-10 14:08:28 -07:00
Benjamin Kramer 66addf8e80 Revert "Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in", "PR45083: Mark statement expressions as being dependent if they appear in"
This reverts commit f545ede91c.
This reverts commit bdad0a1b79.

This crashes clang. I'll follow up with reproduction instructions.
2020-03-05 14:14:31 +01:00
Richard Smith f545ede91c Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in
TreeTransform if the 'dependent' flag would change.
2020-03-04 13:19:49 -08:00