Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
llvm-svn: 315107
This was done for CUDA functions in r261779, and for the same
reason this also needs to be done for OpenCL. An arbitrary
function could have a barrier() call in it, which in turn
requires the calling function to be convergent.
llvm-svn: 315094
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315087
Previously we may erroneously try to capture locally declared static
variables, which will lead to crash for target-based constructs.
Patch fixes this problem.
llvm-svn: 315076
The Cpu Init functionality is required for the target
attribute, so this patch simply splits it out into its own
function, exactly like CpuIs and CpuSupports.
llvm-svn: 315075
In C++11 variable to global variables are considered as constant
expressions and these variables are not captured in the outlined
regions. Patch allows capturing of such variables in the OpenMP regions.
llvm-svn: 315074
This patch is an attempt to clarify and simplify generation and
propagation of TBAA information. The idea is to pack all values
that describe a memory access, namely, base type, access type and
offset, into a single structure. This is supposed to make further
changes, such as adding support for unions and array members,
easier to prepare and review.
DecorateInstructionWithTBAA() is no more responsible for
converting types to tags. These implicit conversions not only
complicate reading the code, but also suggest assigning scalar
access tags while we generally prefer full-size struct-path tags.
TBAAPathTag is replaced with TBAAAccessInfo; the latter is now
the type of the keys of the cache map that translates access
descriptors to metadata nodes.
Fixed a bug with writing to a wrong map in
getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()).
We now check for valid base access types every time we
dereference a field. The original code only checks the top-level
base type. See isValidBaseType() / isTBAAPathStruct() calls.
Some entities have been renamed to sound more adequate and less
confusing/misleading in presence of path-aware TBAA information.
Now we do not lookup twice for the same cache entry in
getAccessTagInfo().
Refined relevant comments and descriptions.
Differential Revision: https://reviews.llvm.org/D37826
llvm-svn: 315048
code size.
Currently clang expands a call to __builtin_os_log_format into a long
sequence of instructions at the call site, causing code size to
increase in some cases.
This commit attempts to reduce code size by emitting a helper function
that can be shared by calls to __builtin_os_log_format with similar
formats and arguments. The helper function has linkonce_odr linkage to
enable the linker to merge identical functions across translation units.
Attribute 'noinline' is attached to the helper function at -Oz so that
the inliner doesn't inline functions that can potentially be merged.
This commit also fixes a bug where the generated IR writes past the end
of the buffer when "%m" is the last specifier appearing in the format
string passed to __builtin_os_log_format.
Original patch by Duncan Exon Smith.
rdar://problem/34065973
rdar://problem/34196543
Differential Revision: https://reviews.llvm.org/D38606
llvm-svn: 315045
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
llvm-svn: 315015
If we resolve an overloaded operator call to a specific function during
template definition, don't perform ADL during template instantiation.
Doing so finds overloads that we're not supposed to find.
llvm-svn: 315005
If the `defaultmap(tofrom:scalar)` clause is specified, the scalars must
be mapped with 'tofrom' modifiers, otherwise they must be captured as
firstprivates.
llvm-svn: 314995
This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.
Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38503
llvm-svn: 314979
This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.
Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38503
llvm-svn: 314977
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
Passes 'new-pass-manager' option to the linker plugin when the new pass
manager is enabled.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314964
In its place, track on the canonical function declaration whether there is a
declaration with a body (and if so, which one). This brings function definition
handling in line with what we do in all other contexts, and is necessary to
allow us to merge declarations within multiple definitions of the same function
(eg, PR33924).
No functionality change intended.
llvm-svn: 314955
As reported on cfe-commits, r314262 resulted in tentatively-defined
variables not being excluded for the warning.
Patch By: Elizabeth Andrews
llvm-svn: 314939
Currently block is translated to a structure equivalent to
struct Block {
void *isa;
int flags;
int reserved;
void *invoke;
void *descriptor;
};
Except invoke, which is the pointer to the block invoke function,
all other fields are useless for OpenCL, which clutter the IR and
also waste memory since the block struct is passed to the block
invoke function as argument.
On the other hand, the size and alignment of the block struct is
not stored in the struct, which causes difficulty to implement
__enqueue_kernel as library function, since the library function
needs to know the size and alignment of the argument which needs
to be passed to the kernel.
This patch removes the useless fields from the block struct and adds
size and align fields. The equivalent block struct will become
struct Block {
int size;
int align;
generic void *invoke;
/* custom fields */
};
It also changes the pointer to the invoke function to be
a generic pointer since the address space of a function
may not be private on certain targets.
Differential Revision: https://reviews.llvm.org/D37822
llvm-svn: 314932
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
https://reviews.llvm.org/D38371
This patch implements codegen for the combined 'teams distribute" OpenMP pragma and adds regression tests for all its clauses.
llvm-svn: 314905
The recent fix in D38258 was wrong: getAuxTriple() only returns
non-null values for the CUDA toolchain. That is why the now added
test for PPC and X86 failed.
Differential Revision: https://reviews.llvm.org/D38372
llvm-svn: 314902
We were injecting the function into the wrong semantic context, resulting in it
failing to be registered as a global for redeclaration lookup. As a
consequence, we accepted invalid code since r310616.
Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot
more often. It turned out that warning codepath was non-conforming, because it
did not cause us to inject the implicitly-declared function into the enclosing
block scope. We now only warn if the type of the out-of-scope declaration
doesn't match the type of an implicitly-declared function; in all other cases,
we produce the normal warning for an implicitly-declared function.
llvm-svn: 314871
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
In C++, such initialization of std::array<T, N> types is guaranteed to work by
the standard, is completely idiomatic, and the "suggested" alternative from
Clang was technically invalid.
llvm-svn: 314838
declaration.
Patch allows using of the `#pragma omp declare target`| `#pragma omp end
declare target` directives inside the structures if we need to mark as
declare target only some static members.
llvm-svn: 314833
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
Currently clang allows the following code
int a;
int b = (const int) a;
However it does not the following code
int4 a;
int4 b = (const int4) a;
This is because Clang compares the qualified types instead of unqualified types for vector type casting, which causes the inconsistency.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D38463
llvm-svn: 314802
This patch fixes clang to propagate complete TBAA information for
atomic accesses and not just the final access types. Prepared
against D38456 and requires it to be committed first.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38460
llvm-svn: 314784
With this patch we implement a concept of TBAA access descriptors
that are capable of representing both scalar and struct-path
accesses in a generic way.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38456
llvm-svn: 314780
Don't emit alignment checks which the IR constant folder throws away.
I've tested this out on X86FastISel.cpp. While this doesn't decrease
end-to-end compile-time significantly, it results in 122 fewer type
checks (1% reduction) overall, without adding any real complexity.
Differential Revision: https://reviews.llvm.org/D37544
llvm-svn: 314752
- it made the bots v angry!
I'm not exactly sure why the assertion doesn't hold - if anyone has any insight - would appreciate it.
Thanks!
llvm-svn: 314748
In passing:
- change the name of the function to pasteTokens c/w coding standards
- rename CurToken to CurTokenIdx (since it is not the token, but the index)
- add doxygen comments to document some of pasteTokens' functionality
- use parameter names different from the data member names.
This will be useful for implementing __VA_OPT__ (https://reviews.llvm.org/D35782#inline-322587)
llvm-svn: 314747
Summary:
Also:
- Add support for some older Myriad CPUs that were missing.
- Fix some incorrect compiler defines for exisitng CPUs.
Reviewers: jyknight
Subscribers: fedor.sergeev
Differential Revision: https://reviews.llvm.org/D37551
llvm-svn: 314706
This commit simplifies the interface for the refactoring action rules and the
refactoring requirements. It merges the selection constraints and the selection
requirements into one class. The refactoring actions rules must now be
implemented using subclassing instead of raw function / lambda pointers. This
change also removes a bunch of template-based traits and other
template definitions that are now redundant.
Differential Revision: https://reviews.llvm.org/D37681
llvm-svn: 314704
This reverts r314461.
It is warning on user code that uses END_COM_MAP(), which expands to
declare QueryInterface with conflicting exception specifers. I've spent
a while trying to understand why, but haven't been able to extract a
reduced test case. Let's revert and I'll keep trying.
llvm-svn: 314689
directives.
The argument of the `device` clause in target-based executable
directives must be captured to support codegen for the `target`
directives with the `depend` clauses.
llvm-svn: 314686
Summary:
This patch fixes a regression introduced in r312904, where the formatter confuses
the `else` in `#else` with an `else` of an `if-else` statement.
For example, formatting this code with google style
```
#ifdef A
int f() {}
#else
int f() {}
#endif
```
resulted in
```
#ifdef A
int f() {}
#else
int f() {
}
#endif
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37973
llvm-svn: 314683
Simplified and generalized codegen for non-offloading part that works if
offloading is failed or condition of the `if` clause is `false`.
llvm-svn: 314670
This patch fixes misleading names of entities related to getting,
setting and generation of TBAA access type descriptors.
This is effectively an attempt to provide a review for D37826 by
breaking it into smaller pieces.
Differential Revision: https://reviews.llvm.org/D38404
llvm-svn: 314657
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute.
The main goal is to add further flexibility to the attribute and allow
for it to be used easily with templates.
The main additions are a new type (DependentAddressSpaceType) alongside
its TypeLoc and its mangling. As well as the logic required to support
dependent address spaces which mainly resides in TreeTransform.h and
SemaType.cpp.
llvm-svn: 314649
- MacroArgs already knows the maximum number of arguments that can be supplied to the macro. No need to pass MacroInfo (information about the macro definition) to the call to getPreExpArgument (which by the way might benefit from being called getExpandedArgument() ?) for it to compute the number of arguments.
llvm-svn: 314593
function-style cast.
This fires for cases such as
T(x);
... where 'x' was previously declared and T is a type. This construct declares
a variable named 'x' rather than the (probably expected) interpretation of a
function-style cast of 'x' to T.
llvm-svn: 314570
Apparently, the MSVC SDK has a strange implementation that
causes a number of implicit functions as well as a template member
function of the IUnknown type. This patch allows these as InterfaceLike
types as well.
Additionally, it corrects the behavior where extern-C++ wrapped around an
Interface-Like type would permit an interface-like type to exist in a namespace.
Differential Revision: https://reviews.llvm.org/D38303
llvm-svn: 314557
Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized.
supersedes D33278, D35774
Differential Revision: https://reviews.llvm.org/D37413
llvm-svn: 314494
Fixes nullability fix-it for `id<SomeProtocol>`. With this change
nullability specifier is inserted after ">" instead of between
"id" and "<".
rdar://problem/34260995
Reviewers: jordan_rose, doug.gregor, ahatanak, arphaman
Reviewed By: jordan_rose
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38327
llvm-svn: 314473
C11 standard refers to the unsigned counterpart of the type ptrdiff_t
in the paragraph 7.21.6.1p7 where it defines the format specifier %tu.
In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case,
in particular, Clang didn't diagnose %tu issues at all, i.e.
it didn't emit any warnings on the code printf("%tu", 3.14).
In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type
similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc)
and fix -Wformat diagnostics for %tu plus the emitted fix-it as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D38270
llvm-svn: 314470
As reported in https://bugs.llvm.org/show_bug.cgi?id=33235,
a noexcept function was unable to inherit from a nothrow defaulted
constructor. Attribute "nothrow" is supposed to be semantically
identical to noexcept, and in fact, a number of other places in the
code treat them identically.
This patch simply checks the RecordDecl for the correct attribute in
the case where no other exception specifier was set.
Differential Revision: https://reviews.llvm.org/D38209
llvm-svn: 314462
I discovered it was possible to create a 'nothrow' noexcept(false)
function, which is both non-sensical as well as seemingly breaking.
This patch warns if attribute nothrow is used with anything besides "noexcept".
"noexcept(true)" isn't possible, because the noexcept decl isn't parsed until
later.
Differential Revision: https://reviews.llvm.org/D38205
llvm-svn: 314461
Currently AMDGPU inline asm only allow v and s as register names in constraints.
This patch allows the following register names in constraints: (n, m is unsigned integer, n < m)
v
s
{vn} or {v[n]}
{sn} or {s[n]}
{S} , where S is a special register name
{v[n:m]}
{s[n:m]}
Differential Revision: https://reviews.llvm.org/D37568
llvm-svn: 314452
to have child entries describing the template parameters. This will
be on by default for SCE tuning.
Differential Revision: https://reviews.llvm.org/D14358
llvm-svn: 314444
The oldest versions of GCC we support (before 5) didn't support that
trait. is_trivial is stronger superset that clang::Token fulfills, so
just use that instead.
llvm-svn: 314391
Refactor MacroArgs to use TrailingObjects when creating a variably sized object on the heap to store the unexpanded tokens immediately after the MacroArgs object.
llvm-svn: 314372
This fixes a bug where clang would emit instructions to reclaim a value
that's going to be __bridge-casted to CF.
rdar://problem/34687542
llvm-svn: 314370
ExternalASTMerger has hitherto relied on being able to look up
any Decl through its named DeclContext chain. This works for
many cases, but causes problems for function-local structs,
which cannot be looked up in their containing FunctionDecl. An
example case is
void f() {
{ struct S { int a; }; }
{ struct S { bool b; }; }
}
It is not possible to lookup either of the two Ses individually
(or even to provide enough information to disambiguate) after
parsing is over; and there is typically no need to, since they
are invisible to the outside world.
However, ExternalASTMerger needs to be able to complete either
S on demand. This led to an XFAIL on test/Import/local-struct,
which this patch removes. The way the patch works is:
It defines a new data structure, ExternalASTMerger::OriginMap,
which clients are expected to maintain (default-constructing
if the origin does not have an ExternalASTMerger servicing it)
As DeclContexts are imported, if they cannot be looked up by
name they are placed in the OriginMap. This allows
ExternalASTMerger to complete them later if necessary.
As DeclContexts are imported from an origin that already has
its own OriginMap, the origins are forwarded – but only for
those DeclContexts that are actually used. This keeps the
amount of stored data minimal.
The patch also applies several improvements from review:
- Thoroughly documents the interface to ExternalASTMerger;
- Adds optional logging to help track what's going on; and
- Cleans up a bunch of braces and dangling elses.
Differential Revision: https://reviews.llvm.org/D38208
llvm-svn: 314336
ToolChain::TranslateArgs() returns nullptr if no changes are performed.
This would currently mean that OpenMPArgs are lost. Patch fixes this
by falling back to simply using OpenMPArgs in that case.
Differential Revision: https://reviews.llvm.org/D38259
llvm-svn: 314330
AuxTriple is not set if host and device share a toolchain. Also,
removing an argument modifies the DAL which needs to be returned
for future use.
(Move tests back to offload-openmp.c as they are not related to GPUs.)
Differential Revision: https://reviews.llvm.org/D38258
llvm-svn: 314329
Parsing the argument after -Xopenmp-target allocates memory that needs
to be freed. Associate it with the final DerivedArgList after we know
which one will be used.
Differential Revision: https://reviews.llvm.org/D38257
llvm-svn: 314328
https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single
JavaRightLogicalShift token. This broke formatting of generics nested more than
two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for
parseAngle().
Luckily, just deleting JavaRightLogicalShift fixes things without breaking the
test added in r299952, so do that.
https://reviews.llvm.org/D38291
llvm-svn: 314325
Added missing addrspacecast case in alignment computation
logic of pointer type emission in IR generation.
Differential Revision: https://reviews.llvm.org/D37804
llvm-svn: 314304
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
Summary:
NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on the same line as the "namespace" keyword.
It occurs in Allman, GNU and Linux styles and whenever BraceWrapping.AfterNamespace is true.
Before:
```lang=cpp
namespace a
{
void f();
void g();
}
```
After:
```lang=cpp
namespace a
{
void f();
void g();
} // namespace a
```
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37904
llvm-svn: 314279
Keep space before or after the &/&& tokens, but not both. For example,
auto [x,y] = a;
auto &[xr, yr] = a; // LLVM style
auto& [xr, yr] = a; // google style
Differential Revision:https://reviews.llvm.org/D35743
llvm-svn: 314264
Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
middle-end.
This change emits the section information for all targets.
Patch By: Elizabeth Andrews
Differential Revision:https://reviews.llvm.org/D36487
llvm-svn: 314262
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
It was brought up in response to my last implementation for
this struct-as-interface features that at least 1 header in
the MS SDK uses "extern C++" around an IUnknown declaration.
The previous implementation demanded that this type exist
in the TranslationUnit DeclContext. This small change simply
also allows in the situation where we're extern "C++".
llvm-svn: 314235
When selecting constructors for initializing an object of type T from a single
expression of class type U, also consider conversion functions of U that
convert to T (rather than modeling such conversions as calling a conversion
function and then calling a constructor).
This approach is proposed as the resolution for the defect, and is also already
implemented by GCC.
llvm-svn: 314231
Discovered that 'nothrow' (which is supposed to be an alias for noexcept)
was not warning with a throw inside of it. This patch corrects the behavior
previously created to add 'nothrow' to this list.
Differential Revision: https://reviews.llvm.org/D38203
llvm-svn: 314229
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
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314217
Summary: This adds an ext/ header include category for google style.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D38243
llvm-svn: 314211
This patch fixes clang to decorate reference accesses as pointers
and not as "omnipotent chars".
Differential Revision: https://reviews.llvm.org/D38074
llvm-svn: 314209
directives.
If the variable is used in the target-based region but is not found in
any private|mapping clause, then generate implicit firstprivate|map
clauses for these implicitly mapped variables.
llvm-svn: 314205
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314188
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314177
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
Summary: Enable the -nocudalib flag for the OpenMP device offloading toolchain as well. Currently it can only be used for the CUDA toolchain.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37913
llvm-svn: 314164
Summary: When composing the output file name, the path to the file is being dropped. The full path is required.
Reviewers: Hahnfeld, ABataev, caomhin, carlo.bertolli, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37912
llvm-svn: 314156
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314150
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 314145
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
This commit fixes a bug in the handling of storage-only __fp16 vectors
where clang didn't promote __fp16 vector operands to float vectors.
Conceptually, it performs the following transformation on the AST in
CreateBuiltinBinOp and CreateBuiltinUnaryOp:
(Before)
typedef __fp16 half4 __attribute__ ((vector_size (8)));
typedef float float4 __attribute__ ((vector_size (16)));
half4 hv0, hv1, hv2, hv3;
hv0 = hv1 + hv2 + hv3;
(After)
float4 t0 = (float4)hv1 + (float4)hv2;
float4 t1 = t0 + (float4)hv3;
hv0 = (half4)t1;
Note that this commit fixes the bug for targets that set
HalfArgsAndReturns to true (ARM and ARM64). Targets using intrinsics
such as llvm.convert.to.fp16 to handle __fp16 are still broken.
rdar://problem/20625184
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 314056
This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.
We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.
We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.
llvm-svn: 314037
body of global block invoke functions.
This commit fixes an infinite loop in IRGen that occurs when compiling
the following code:
void FUNC2() {
static void (^const block1)(int) = ^(int a){
if (a--)
block1(a);
};
}
This is how IRGen gets stuck in the infinite loop:
1. GenerateBlockFunction is called to emit the body of "block1".
2. GetAddrOfGlobalBlock is called to get the address of "block1". The
function calls getAddrOfGlobalBlockIfEmitted to check whether the
global block has been emitted. If it hasn't been emitted, it then
tries to emit the body of the block function by calling
GenerateBlockFunction, which goes back to step 1.
This commit prevents the inifinite loop by building the global block in
GenerateBlockFunction before emitting the body of the block function.
rdar://problem/34541684
Differential Revision: https://reviews.llvm.org/D38118
llvm-svn: 314029
Summary:
It will move destructors and operators to the end of completion list.
Destructors and operators are currently very high on the completion
list, as they have the same priority as member functions. However,
they are clearly not something users usually choose in completion
lists.
Reviewers: arphaman, erikjv, bkramer, krasimir
Reviewed By: arphaman
Subscribers: eraman, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D38081
llvm-svn: 314019
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
Add an option to emit limited coverage info for unused decls. It's just a
cl::opt for now to allow us to experiment quickly.
When building llc, this results in an 84% size reduction in the llvm_covmap
section, and a similar size reduction in the llvm_prf_names section. In
practice I expect the size reduction to be roughly quadratic with the size of
the program.
The downside is that coverage for headers will no longer be complete. This will
make the line/function/region coverage metrics incorrect, since they will be
artificially high. One mitigation would be to somehow disable those metrics
when using limited-coverage=true.
This is related to: llvm.org/PR34533 (make SourceBasedCodeCoverage scale)
Differential Revision: https://reviews.llvm.org/D38107
llvm-svn: 314002
Summary:
ObjC classes have two associated symbols, one for the class and one for the
metaclass.
This change overloads `CodegenNameGenerator::getAllManglings` to produce both
class and metaclass symbols.
While this function is called by `clang_Cursor_getCXXManglings`, it's only
called for CXXRecordDecl and CXXMethodDecl, and so libclang's behavior is
unchanged.
Reviewers: arphaman, abdulras, alexshap, compnerd
Reviewed By: compnerd
Subscribers: compnerd
Differential Revision: https://reviews.llvm.org/D37671
llvm-svn: 313997
If the captured variable has re-declaration we may end up with the
situation where the captured variable is the re-declaration while the
referenced variable is the canonical declaration (or vice versa). In
this case we may generate wrong code. Patch fixes this situation.
llvm-svn: 313995
This is to fix PR31620. MaxAtomicInlineWidth is set to 128 for x86_64. However
for target without cx16 support, 128 atomic operation will generate __sync_*
libcalls. The patch set MaxAtomicInlineWidth to 64 if the target doesn't support
cx16.
Differential Revision: https://reviews.llvm.org/D38046
llvm-svn: 313992
This patch introduces a class that can help to build tools that require cross
translation unit facilities. This class allows function definitions to be loaded
from external AST files based on an index. In order to use this functionality an
index is required. The index format is a flat text file but it might be
replaced with a different solution in the near future. USRs are used as names to
look up the functions definitions. This class also does caching to avoid
redundant loading of AST files.
Right now only function defnitions can be loaded using this API because this is
what the in progress cross translation unit feature of the Static Analyzer
requires. In to future this might be extended to classes, types etc.
Differential Revision: https://reviews.llvm.org/D34512
llvm-svn: 313975
Summary:
This ignores case while sorting using-declarations, fixing a case where `_` would appear between lowercase and uppercase characters.
It also applies stable sort, so that replacements for the exact same using declarations are not generated.
Reviewers: klimek, alexfh
Reviewed By: alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37263
llvm-svn: 313963
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
llvm-svn: 313955
I've been unable to find any cases whose behavior is actually changed by this,
but only because an implicitly deleted destructor also results in it being
impossible to have a trivial (non-deleted) copy constructor, which the place
where this really matters (choosing whether to pass a class in registers)
happens to also check.
llvm-svn: 313948
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
This recommits r313722, which was reverted in r313725 because clang
couldn't build compiler-rt. It failed to build because there were
function declarations that were missing 'noescape'. That has been fixed
in r313929.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313945
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
Sema::InstantiateClass should check only exception specs added during
class instantiation and ignore already present delayed specs. This fixes
a case where we instantiate a class before parsing member initializers,
check exceptions for a different class and fail to find a member
initializer. Which is required for comparing exception specs for
explicitly-defaulted and implicit default constructor. With the fix we
are still checking exception specs but only after member initializers
are present.
Removing errors in crash-unparsed-exception.cpp is acceptable according
to discussion in PR24000 because other compilers accept code in
crash-unparsed-exception.cpp as valid.
rdar://problem/34167492
Reviewers: davide, rsmith
Reviewed By: rsmith
Subscribers: dim, cfe-commits
Differential Revision: https://reviews.llvm.org/D37881
llvm-svn: 313906
It fixes a crash in CodeGen when we are trying to generate code for
initializer expression created before template instantiation, like
CallExpr '<dependent type>'
|-UnresolvedLookupExpr '<overloaded function type>' lvalue (ADL) = 'parse'
`-DeclRefExpr 'Buffer<N>' lvalue ParmVar 'buffer' 'Buffer<N>'
rdar://problem/33888545
Reviewers: rsmith, ahatanak
Reviewed By: ahatanak
Subscribers: aemerson, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D38009
llvm-svn: 313896
Fix for too aggressive error err_type_defined_in_enum introduced in
r313386. Defining tags inside enumerations is prohibited in C++ but
allowed in C.
Reviewers: aaron.ballman, rnk, doug.gregor
Reviewed By: rnk
Subscribers: alberto_magni, cfe-commits
Differential Revision: https://reviews.llvm.org/D38109
llvm-svn: 313894
If the captured variable has some redeclarations we may run into the
situation where the redeclaration is used instead of the canonical
declaration and we may consider this variable as one not captured
before.
llvm-svn: 313880
__interface types are allowed in MSVC to have "property" data members
(marked with declspec property). This patch alters Sema to allow property
data members.
Differential Revision: https://reviews.llvm.org/D38092
llvm-svn: 313828
This patch fixes broken preamble-skipping when the preamble region includes a byte order mark (BOM). Previously, parsing would fail if preamble PCH generation was enabled and a BOM was present.
This also fixes preamble invalidation when a BOM appears or disappears. This may seem to be an obscure edge case, but it happens regularly with IDEs that pass buffer overrides that never (or always) have a BOM, yet the underlying file from the initial parse that generated a PCH might (or might not) have a BOM.
I've included a test case for these scenarios.
Differential Revision: https://reviews.llvm.org/D37491
llvm-svn: 313796
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
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
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
Correctly determine when [ is part of a structured binding instead of a
lambda.
To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken
Before:
auto const const &&[x, y] { A *i };
After:
auto const const && [x, y]{A * i};
Fixing formatting of the type of the structured binding is still missing.
llvm-svn: 313742
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
This reverts commit r313722.
It looks like compiler-rt/lib/tsan/rtl/tsan_libdispatch_mac.cc cannot be
compiled because some of the functions declared in the file do not match
the ones in the SDK headers (which are annotated with 'noescape').
llvm-svn: 313725
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313722
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 313720
overridden methods when compiling for non-ARC.
Previously, clang would error out when compiling for ARC, but didn't
print any diagnostics when compiling for non-ARC.
This was pointed out in the patch review for attribute noescape:
https://reviews.llvm.org/D32210
llvm-svn: 313717
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
When the value specified for n in ordered(n) is larger than the number of loops a segmentation fault can occur in one of two ways when attempting to print out a diagnostic for an associated depend(sink : vec):
1) The iteration vector vec contains less than n items
2) The iteration vector vec contains a variable that is not a loop control variable
This patch addresses both of these issues.
Differential Revision: https://reviews.llvm.org/D38049
llvm-svn: 313675
Summary:
According to C99 6.3.2.1p1, structs and unions with nested
const-qualified fields (that is, const-qualified fields
declared at some recursive level of the aggregate) are not
modifiable lvalues. However, Clang permits assignments of
these lvalues.
With this patch, we both prohibit the assignment of records
with const-qualified fields and emit a best-effort diagnostic.
This fixes https://bugs.llvm.org/show_bug.cgi?id=31796 .
Committing on behalf of bevinh (Bevin Hansson).
Reviewers: rtrieu, rsmith, bjope
Reviewed By: bjope
Subscribers: Ka-Ka, rogfer01, bjope, fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D37254
llvm-svn: 313628
Most of the work was already done when we introduced a look-behind based
lambda introducer detection.
This patch finishes the transition by completely relying on the simple
lambda introducer detection and simply recursing into normal
brace-parsing code to parse until the end of the introducer.
This fixes initializers in lambdas, including nested lambdas.
Before:
auto a = [b = [c = 42]{}]{};
auto b = [c = &i + 23]{};
After:
auto a = [b = [c = 42] {}] {};
auto b = [c = &i + 23] {};
llvm-svn: 313622
As a special case, throw away deferred regions for trailing returns.
This allows the closing curly brace to have a count, and is less
distracting.
llvm-svn: 313603
error'ed field for a template class' default ctor.
The two examples in the test would both cause a compiler assert when attempting
to calculate the exception specifier for the default constructor for the
template classes. The problem was that dependents of this function expect that
Field->getInClassInitializer (including canThrow) is not nullptr. However, if
the template's initializer has an error, exactly that situation happens.
This patch simply sets the field to be invalid.
Differential Revision: https://reviews.llvm.org/D37865
llvm-svn: 313569
This arranges more of the Intel and AMD CPUs into fallthrough positions based on their features. We may be able to merge this new AMD set with the BTVER or BDVER sets but I didn't look that closely.
Differential Revision: https://reviews.llvm.org/D37941
llvm-svn: 313497
https://bugs.llvm.org/show_bug.cgi?id=34266
For e.g.
struct A {
void f(int);
static void f(char);
};
struct B {
auto foo() {
return [&] (auto a) {
A::f(a); // this should not cause a capture of '*this'
};
}
};
The patch does the following:
1) It moves the check to attempt an implicit capture of '*this' by reference into the more logical location of when the call is actually built within ActOnCallExpr (as opposed to when the unresolved-member-lookup node is created).
- Reminder: A capture of '*this' by value has to always be an explicit capture.
2) It additionally checks whether the naming class of the UnresolvedMemberExpr ('A' in the example above) is related to the enclosing class ('B' above).
P.S. If you have access to ISO-C++'s CWG reflector, see this thread for some potentially related discussion: http://lists.isocpp.org/core/2017/08/2851.php
llvm-svn: 313487
Summary:
For a lot of older CPUs we have a 1:1 mapping between CPU name and enum name. But many of them are effectively aliases of each other and as a result are always repeated together at every usage
This patch removes most of the duplication. It also uses StringSwitch::Cases to make the many to one mapping in the StringSwitch more obvious.
Reviewers: RKSimon, spatel, zvi, igorb
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37938
llvm-svn: 313462
Summary:
Restore the `__builtin_wasm_rethrow` builtin deleted in D37931. On second
thought, it appears it can be used to implement `__cxa_rethrow`.
Reviewers: dschuff, sunfish
Reviewed By: dschuff
Subscribers: jfb, sbc100, jgravelle-google
Differential Revision: https://reviews.llvm.org/D37942
llvm-svn: 313430
This patch replaces the perm2f128 intrinsics with native shuffle vectors.
This uses a pretty simple approach to allocate source 0 to the lower half input and source 1 to the upper half input. Then its just a matter of filling in the indices to use either the lower or upper half of that specific source. This can result in the same source being used by both operands. InstCombine or SelectionDAGBuilder should be able to clean that up.
Differential Revision: https://reviews.llvm.org/D37892
llvm-svn: 313418
Summary:
Remove `__builtin_wasm_rethrow` builtin. I thought it was required to implement
`__cxa_rethrow` function in libcxxabi, but it turned out it will be using
`__builtin_wasm_throw` instead.
Reviewers: dschuff, jgravelle-google
Reviewed By: jgravelle-google
Subscribers: jfb, sbc100, jgravelle-google
Differential Revision: https://reviews.llvm.org/D37931
llvm-svn: 313402
The __builtin_ia32_pbroadcastq512_mem_mask we were previously trying to use in 32-bit mode is not implemented in the x86 backend and causes isel to fail in release builds. In debug builds it fails even earlier during legalization with an llvm_unreachable.
While there add the missing test case for this intrinsic for this for 64-bit mode.
This fixes PR34631. D37668 should be able to recover this for 32-bit mode soon. But I wanted to fix the crash ahead of that.
llvm-svn: 313392
This fixes PR28903 by avoiding access check for inner enum constant. We
are performing access check because one enum constant references another
and because enum is defined in CXXRecordDecl. But access check doesn't
work because FindDeclaringClass doesn't expect more than one EnumDecl
and because inner enum has access AS_none due to not being an immediate
child of a record.
The change detects an enum is defined in wrong place and allows to skip
parsing its body. Access check is skipped together with body parsing.
There was no crash in C, added test case to cover the new error.
rdar://problem/28530809
Reviewers: rnk, doug.gregor, rsmith
Reviewed By: doug.gregor
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37089
llvm-svn: 313386
In CUDA-9 some of device-side math functions that we need are conditionally
defined within '#if _GLIBCXX_MATH_H'. We need to temporarily undo the guard
around inclusion of math_functions.hpp.
Differential Revision: https://reviews.llvm.org/D37906
llvm-svn: 313369
__interface objects in MSVC are permitted to inherit from __interface types,
and interface-like types.
Additionally, there are two default interface-like types
(IUnknown and IDispatch) that all interface-like
types must inherit from.
Differential Revision: https://reviews.llvm.org/D37308
llvm-svn: 313364
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"**
**Problem:**
Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always!
**Patch description:**
A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not.
Reviewers: djasper, krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37845
Contributed by @PriMee!
llvm-svn: 313354
Specifically, typo correction should be done before dispatching between
different kinds of binary operations like pseudo-object assignment,
overloaded binary operation, etc.
Without this change we hit an assertion
Assertion failed: (!LHSExpr->hasPlaceholderType(BuiltinType::PseudoObject)), function CheckAssignmentOperands
when in Objective-C we reference a property without `self` and there are
2 equally good typo correction candidates: ivar and a class name. In
this case LHS expression in `BuildBinOp` is
CXXDependentScopeMemberExpr
`-TypoExpr
and instead of handling Obj-C property assignment as pseudo-object
assignment, we call `CreateBuiltinBinOp` which corrects typo to
ObjCPropertyRefExpr '<pseudo-object type>'
but cannot handle pseudo-objects and asserts about it (indirectly,
through `CheckAssignmentOperands`).
rdar://problem/33102722
Reviewers: rsmith, ahatanak, majnemer
Reviewed By: ahatanak
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37322
llvm-svn: 313323
Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols
will eventually be exported through the named "public" module. This is
in support of a common pattern in the Darwin ecosystem where a single
public framework is constructed of several private frameworks, with
(currently) header duplication and some support from the linker.
Addresses rdar://problem/34438420.
llvm-svn: 313316
When a static_assert fails, dig out a specific condition to diagnose,
using the same logic that we use to find the enable_if condition to
diagnose.
llvm-svn: 313315
These arguments don't (not yet at least) make sense for
the wasm lld port.
Subscribers: jfb, dschuff, jgravelle-google, aheejin
Differential Revision: https://reviews.llvm.org/D36595
llvm-svn: 313299
This commit ensures that CommonOptionsParser works with subcommands. This allows
clang-refactor to use the CommonOptionsParser.
Differential Revision: https://reviews.llvm.org/D37618
llvm-svn: 313260
local-rename action
This commit introduces the clang-refactor tool alongside the local-rename action
which uses the existing renaming engine used by clang-rename. The tool
doesn't actually perform the source transformations yet, it just provides
testing support. This commit also moves only one test from clang-rename over to
test/Refactor. I will continue to move the other tests throughout
development of clang-refactor.
The following options are supported by clang-refactor:
-v: use verbose output
-selection: The source range that corresponds to the portion of the source
that's selected (currently only special command test:<file> is supported).
Please note that a follow-up commit will migrate clang-refactor to
libTooling's common option parser, so clang-refactor will be able to use
the common interface with compilation database and options like -p, -extra-arg,
etc.
The testing support provided by clang-refactor is described below:
When -selection=test:<file> is given, clang-refactor will parse the selection
commands from that file. The selection commands are grouped and the specified
refactoring action invoked by the tool. Each command in a group is expected to
produce an identical result. The precise syntax for the selection commands is
described in a comment in TestSupport.h.
Differential Revision: https://reviews.llvm.org/D36574
llvm-svn: 313244
Summary:
To improve CodeView quality for static member functions, we need to make the
static explicit. In addition to a small change in LLVM's CodeViewDebug to
return the appropriate MethodKind, this requires a small change in Clang to
note the staticness in the debug info metadata.
Subscribers: aprantl, hiraditya
Differential Revision: https://reviews.llvm.org/D37715
llvm-svn: 313192
This reverts rL313102 because it still fails some build bot tests.
On many linux bots it fails with the following error.
error: invalid linker name in argument '-fuse-ld=lld'
and on some windows bots also because there is no ld.lld.exe
lld-link.exe: warning: ignoring unknown argument: -fuse-ld=lld
llvm-svn: 313104
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
This is a re-apply of rL313082 which was reverted in rL313088
due to failing buildbot tests.
Differential Revision: https://reviews.llvm.org/D37727
llvm-svn: 313102
This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the way RTTI is stored into
function prologue data.
On Darwin, addresses stored in prologue data can't require run-time fixups and
must be PC-relative. Run-time fixups are undesirable because they necessitate
writable text segments, which can lead to security issues. And absolute
addresses are undesirable because they break PIE mode.
The fix is to create a private global which points to the RTTI, and then to
encode a PC-relative reference to the global into prologue data.
Differential Revision: https://reviews.llvm.org/D37597
llvm-svn: 313096
We make the same decision when compiling the kernel or kexts -- we
should do this in -ffreestanding mode as well to avoid size regressions
in a potentially large set of firmware projects.
It's still possible to get uwtable information in -ffreestanding mode by
compiling with -funwind-tables (I expect this to be a rare case: I
certainly haven't seen any projects like that).
Context: -munwind-tables was enabled by default for some arm targets in
r310006.
Testing: check-clang
rdar://problem/33934446
Differential Revision: https://reviews.llvm.org/D37777
llvm-svn: 313087
Reid Kleckner