r280133. Original commit message:
C++ Modules TS: driver support for building modules.
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280134
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.
Differential Revision: https://reviews.llvm.org/D23840
llvm-svn: 280064
The PPC64 DWARF register-size table did not match the ABI specification (or
GCC, for that matter). Fix that, and add a regression test.
Fixes PR27931.
llvm-svn: 280053
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280035
If there were several nested statements arranged in a way that all of them
end up with the same macro, then the expansion of this macro was assigned
with all the corresponding counters of these statements.
As a result, the wrong counter value was shown for the macro in llvm-cov.
This patch fixes the issue by preventing adding a counter for an expanded
source range if it already has an assigned counter, which is expected
to come from the most specific statement.
Differential Revision: https://reviews.llvm.org/D23160
llvm-svn: 279962
Clang always assumes that files are utf-8. If an invalidly encoded character is
used in an identifier, clang always errors. If it's used in a character
literal, clang warns Winvalid-source-encoding (on by default). Clang never
checks the encoding of things in comments (adding this seems like a nice
feature if it doesn't impact performance).
For cl.exe /utf-8 (which enables /validate-charset), if a bad character is used
in an identifier, it emits both an error and a warning. If it's used in a
literal or a comment, it emits a warning.
So mapping /validate-charset to -Winvalid-source-encoding seems like a fairly
decent fit.
https://reviews.llvm.org/D23945
llvm-svn: 279872
This is triggered when we are compiling an implementation of a module,
it has relative includes to a VFS-mapped module with umbrella headers.
Currently we will find the real path to headers under the umbrella directory,
but the umbrella directories are using virtual path.
rdar://27951255
Thanks Ben and Richard for reviewing the patch!
Differential Revision: http://reviews.llvm.org/D23858
llvm-svn: 279838
Otherwise we can't handle secondary base classes at offsets greater than
2**24. This agrees with libstdc++abi.
We could extend this change to other LLP64 platforms, but then we would
want to update libc++abi and it would require additional review.
Fixes PR29116
llvm-svn: 279786
Clang tracks only start columns, not start-end ranges. CodeView allows for that, but the VS debugger doesn't handle anything less than a complete range well--it either highlights the wrong part of a statement or truncates source lines in the assembly view. It's better to have no column information at all.
So by default, we'll omit the column information for CodeView targeting Windows.
Since the column info is still useful for sanitizers, I've promoted -gcolumn-info (and -gno-column-info) to a CoreOption and added a couple tests to make sure that works for clang-cl.
Differential Revision: https://reviews.llvm.org/D23720
llvm-svn: 279765
This isn't exactly what MSVC does, unfortunately. MSVC does not pass
objects with destructors but no copy constructors by address. More ARM
expertise is required to really understand what should be done here.
Fixes PR29136.
llvm-svn: 279764
Emit proper diagnostics when -Wdocumentation is used with constructs such as:
template<typename T>
using fn = int(T aaa, int ccc);
Previously clang wouldn't recognize the function and complain with
'comment that is not attached to a function declaration'.
Differential Revision: https://reviews.llvm.org/D23860
rdar://problem/27300695
llvm-svn: 279754
If the inline info is not duplicated into the skeleton CU, then there's
value in using -gsplit-dwarf and -gmlt together (to keep all those extra
subprograms out of the skeleton CU, while also producing smaller .dwo
files)
llvm-svn: 279687
per-frame stack usage enough to cause it to hit our stack limit. This is not
ideal; we should find a better way of dealing with this, such as increasing
our stack allocation when built with ASan.
llvm-svn: 279668
Give appropriate warnings with -Wdocumentation for @param comments
that refer to function aliases defined with 'using'. Very similar
to typedef's behavior. This does not add support for
TypeAliasTemplateDecl yet.
Differential Revision: https://reviews.llvm.org/D23783
rdar://problem/27300695
llvm-svn: 279662
In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.
llvm-svn: 279651
Summary:
This patch adds the capability to bundle object files in sections of the host binary using a designated naming convention for these sections. This patch uses the functionality of the object reader already in the LLVM library to read bundled files, and invokes clang with the incremental linking options to create bundle files.
Bundling files involves creating an IR file with the contents of the bundle assigned as initializers of globals binded to the designated sections. This way the bundling implementation is agnostic of the host object format.
The features added by this patch were requested in the RFC discussion in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html.
Reviewers: echristo, tra, jlebar, hfinkel, ABataev, Hahnfeld
Subscribers: mkuron, whchung, cfe-commits, andreybokhanko, Hahnfeld, arpith-jacob, carlo.bertolli, mehdi_amini, caomhin
Differential Revision: https://reviews.llvm.org/D21851
llvm-svn: 279634
Summary:
One of the goals of programming models that support offloading (e.g. OpenMP) is to enable users to offload with little effort, by annotating the code with a few pragmas. I'd also like to save users the trouble of changing their existent applications' build system. So having the compiler always return a single file instead of one for the host and each target even if the user is doing separate compilation is desirable.
This diff proposes a tool named clang-offload-bundler (happy to change the name if required) that is used to bundle files associated with the same user source file but different targets, or to unbundle a file into separate files associated with different targets.
This tool supports the driver support for OpenMP under review in http://reviews.llvm.org/D9888. The tool is used there to enable separate compilation, so that the very first action on input files that are not source files is a "unbundling action" and the very last non-linking action is a "bundling action".
The format of the bundled files is currently very simple: text formats are concatenated with comments that have a magic string and target identifying triple in between, and binary formats have a header that contains the triple and the offset and size of the code for host and each target.
The goal is to improve this tool in the future to deal with archive files so that each individual file in the archive is properly dealt with. We see that archives are very commonly used in current applications to combine separate compilation results. So I'm convinced users would enjoy this feature.
This tool can be used like this:
`clang-offload-bundler -targets=triple1,triple2 -type=ii -inputs=a.triple1.ii,a.triple2.ii -outputs=a.ii`
or
`clang-offload-bundler -targets=triple1,triple2 -type=ii -outputs=a.triple1.ii,a.triple2.ii -inputs=a.ii -unbundle`
I implemented the tool under clang/tools. Please let me know if something like this should live somewhere else.
This patch is prerequisite for http://reviews.llvm.org/D9888.
Reviewers: hfinkel, rsmith, echristo, chandlerc, tra, jlebar, ABataev, Hahnfeld
Subscribers: whchung, caomhin, andreybokhanko, arpith-jacob, carlo.bertolli, mehdi_amini, guansong, Hahnfeld, cfe-commits
Differential Revision: https://reviews.llvm.org/D13909
llvm-svn: 279632
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
llvm-svn: 279557
/Brepro means we want reproducible builds, i.e. we _don't_ want the timestamp
that's needed to be compatible with the incremental linker.
https://reviews.llvm.org/D23805
llvm-svn: 279555
iOS (and other 32-bit ARM variants) always require a valid frame pointer to
improve backtraces. Previously the -fomit-frame-pointer and
-momit-leaf-frame-pointer options were being silently discarded via hacks in
the backend. It's better if Clang configures itself to emit the correct IR and
warns about (ignored) attempts to override this.
llvm-svn: 279546
clang already treats all inputs as utf-8. Warn if anything but utf-8 is passed.
Do this by mapping source-charset to finput-charset, which already behaves like
this. Slightly tweak finput-charset to accept "utf-8" case-insensitively. This
matches gcc's and cl.exe's behavior, and IANA says that character set names are
case-insensitive.
https://reviews.llvm.org/D23807
llvm-svn: 279531
If a call expression represents a method call of a class template,
and the method itself isn't templated, then the method may be considered
to be a template instantiation without template specialization arguments.
No longer crash when we could not find template specialization arguments.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23780
llvm-svn: 279529
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
llvm-svn: 279486
in isDefinedInClangModule() and assume that the incomplete definition
is not defined in the module.
This broke the -gmodules self host recently.
rdar://problem/27894367
llvm-svn: 279485
Fix crash-on-invalid in ObjC Sema by avoiding to rebuild a message
expression to a 'super' class in case the method to call does not exist
(i.e. comes from another missing identifier).
In this case, the typo transform is invoked upon the message expression
in an attempt to solve a typo in a 'super' call parameters, but it
crashes since it assumes the method to call has a valid declaration.
rdar://problem/27305403
llvm-svn: 279481
Structs are currently handled as pointer + byval, which makes AMDGPU
LLVM backend generate incorrect code when structs are used. This patch
changes struct argument to be handled directly and without flattening,
which Clover (Mesa 3D Gallium OpenCL state tracker) will be able to
handle. Flattening would expand the struct to individual elements and
pass each as a separate argument, which Clover can not
handle. Furthermore, such expansion does not fit the OpenCL
programming model which requires to explicitely specify each argument
index, size and memory location.
Patch by Vedran Miletić
llvm-svn: 279463
If they are, we end up with the last intermediary output preserved
in the current directory after compilation.
Added a test case to verify that we're using appropriate filenames
for outputs of different phases.
Differential Revision: https://reviews.llvm.org/D23526
llvm-svn: 279455
This is valid in GNU C, which allows pointers to incomplete enums. GCC
just pretends that the underlying type is 'int' in those cases, follow
that behavior.
llvm-svn: 279374
In certain cases (mostly coming from modules), Sema's idea of the StdNamespace
does not point to the first declaration of namespace std.
Patch by Cristina Cristescu!
Reviewed by Richard Smith.
llvm-svn: 279371
So far macro-generated code was treated by the CloneDetector as normal code.
This caused that some macros where reported as false-positive clones because
large chunks of code coming from otherwise concise macro expansions were treated
as copy-pasted code.
This patch ensures that macros are treated in the same way as literals/function
calls. This prevents macros that expand into multiple statements
from being reported as clones.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23316
llvm-svn: 279367
For example, code samples `isa<Stmt>(S)' and `isa<Expr>(S)'
are no longer considered to be clones.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23555
llvm-svn: 279366
from p0273r0 approved by EWG). We'll eventually need to handle this from the
lexer as well, in order to disallow preprocessor directives preceding the
module declaration and to support macro import.
llvm-svn: 279196
We should ignore paren casts when making sure that the semantic expression
in a PseudoObjectExpr for an ObjC getter is a message send.
This has no other intended functionality change.
Adding a test for this exposed an interesting issue in another test case
that only manifests under ARC. trackNullOrUndefValue() is not properly
suppressing for nil values that are the result of nil propagation from a nil
receiver when the nil is returned from a function. I've added a FIXME for that
missing suppression.
rdar://problem/27290568
llvm-svn: 279181
Summary:
int __builtin_amdgcn_ds_swizzle (int a, int imm);
while imm is a constant.
Differential Revision:
http://reviews.llvm.org/D23682
llvm-svn: 279165
Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type.
Differential Revision: https://reviews.llvm.org/D23361
llvm-svn: 279121
In C, 'extern' is typically used to avoid tentative definitions when
declaring variables in headers, but adding an intializer makes it a
defintion. This is somewhat confusing, so GCC and Clang both warn on it.
In C++, 'extern' is often used to give implictly static 'const'
variables external linkage, so don't warn in that case. If selectany is
present, this might be header code intended for C and C++ inclusion, so
apply the C++ rules.
llvm-svn: 279116
In this mode, there is no need to load any module map and the programmer can
simply use "@import" syntax to load the module directly from a prebuilt
module path. When loading from prebuilt module path, we don't support
rebuilding of the module files and we ignore compatible configuration
mismatches.
rdar://27290316
Differential Revision: http://reviews.llvm.org/D23125
llvm-svn: 279096
The original clone checker tries to find copy-pasted code that is exactly
identical to the original code, up to minor details.
As an example, if the copy-pasted code has all references to variable 'a'
replaced with references to variable 'b', it is still considered to be
an exact clone.
The new check finds copy-pasted code in which exactly one variable seems
out of place compared to the original code, which likely indicates
a copy-paste error (a variable was forgotten to be renamed in one place).
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23314
llvm-svn: 279056
This reverts commit r279003 as it breaks some of our buildbots (e.g.
clang-cmake-aarch64-quick, clang-x86_64-linux-selfhost-modules).
The error is in OpenMP/teams_distribute_simd_ast_print.cpp:
clang: /home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/include/llvm/ADT/DenseMap.h:527:
bool llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT, BucketT>::LookupBucketFor(const LookupKeyT&, const BucketT*&) const
[with LookupKeyT = clang::Stmt*; DerivedT = llvm::DenseMap<clang::Stmt*, long unsigned int>;
KeyT = clang::Stmt*; ValueT = long unsigned int;
KeyInfoT = llvm::DenseMapInfo<clang::Stmt*>;
BucketT = llvm::detail::DenseMapPair<clang::Stmt*, long unsigned int>]:
Assertion `!KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) &&
"Empty/Tombstone value shouldn't be inserted into map!"' failed.
llvm-svn: 279045
trying to write out its macro graph, in case we imported a module that added
another module macro between the most recent local definition and the end of
the module.
llvm-svn: 279024
This patch is to implement sema and parsing for 'teams distribute simd’ pragma.
This patch is originated by Carlo Bertolli.
Differential Revision: https://reviews.llvm.org/D23528
llvm-svn: 279003
Check that ExpandStructures is true before visiting the list of ivars.
rdar://problem/27135221
Differential revision: https://reviews.llvm.org/D22929
llvm-svn: 278956
The previous condition would erroneously mark all CXXRecordDecls
that didn't have any fields as being defined in a clang module.
This patch fixes the condition to only apply to explicit template
instantiations.
<rdar://problem/27771823>
llvm-svn: 278952
This new checker tries to find execution paths on which implicit integral casts
cause definite loss of information: a certainly-negative integer is converted
to an unsigned integer, or an integer is definitely truncated to fit into
a smaller type.
Being implicit, such casts are likely to produce unexpected results.
Patch by Daniel Marjamäki!
Differential Revision: https://reviews.llvm.org/D13126
llvm-svn: 278941
Like SymbolConjured, SymbolMetadata also needs to be uniquely
identified by the moment of its birth.
Such moments are coded by the (Statement, LocationContext, Block count) triples.
Each such triple represents the moment of analyzing a statement with a certain
call backtrace, with corresponding CFG block having been entered a given amount
of times during analysis of the current code body.
The LocationContext information was accidentally omitted for SymbolMetadata,
which leads to reincarnation of SymbolMetadata upon re-entering a code body
with a different backtrace; the new symbol is incorrectly unified with
the old symbol, which leads to unsound assumptions.
Patch by Alexey Sidorin!
Differential Revision: https://reviews.llvm.org/D21978
llvm-svn: 278937
With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger.
The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows.
Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc.
llvm-svn: 278861
This commit adds a traversal of the AST after Sema of a function that diagnoses
unguarded references to declarations that are partially available (based on
availability attributes). This traversal is only done when we would otherwise
emit -Wpartial-availability.
This commit is part of a feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential revision: https://reviews.llvm.org/D23003
llvm-svn: 278826
Unless we overload the default gcc toolchain with an empty string
the system root used in the tests will be ignored if the user builds
clang with a custom gcc toolchain.
llvm-svn: 278806
anonymous union member of a class, we need overload resolution for the move
constructor of the class itself too; we can't rely on Sema to do the right
thing for us for anonymous union types.
llvm-svn: 278763
Summary:
Some function calls in CUDA are allowed to appear in
semantically-correct programs but are an error if they're ever
codegen'ed. Specifically, a host+device function may call a host
function, but it's an error if such a function is ever codegen'ed in
device mode (and vice versa).
Previously, clang made no attempt to catch these errors. For the most
part, they would be caught by ptxas, and reported as "call to unknown
function 'foo'".
Now we catch these errors and report them the same as we report other
illegal calls (e.g. a call from a host function to a device function).
This has a small change in error-message behavior for calls that were
previously disallowed (e.g. calls from a host to a device function).
Previously, we'd catch disallowed calls fairly early, before doing
additional semantic checking e.g. of the call's arguments. Now we catch
these illegal calls at the very end of our semantic checks, so we'll
only emit a "illegal CUDA call" error if the call is otherwise
well-formed.
Reviewers: tra, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23242
llvm-svn: 278759
For the following example:
typedef __attribute__((NSObject)) CGColorRef ColorAttrRef;
@property (strong, nullable) ColorAttrRef color;
The property type should be ObjC NSObject type and the compiler should not emit
error: property with 'retain (or strong)' attribute must be of object type
rdar://problem/27747154
llvm-svn: 278742
Summary:
There's no point to --cuda-path if we then go and include /usr/include
first. And if you install the right packages, Ubuntu will install (very
old) CUDA headers there.
Reviewers: tra
Subscribers: cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D23341
llvm-svn: 278734
We processed unnamed bitfields after our logic for non-vector field
elements in records larger than 128 bits. The vector logic would
determine that the bit-field disqualifies the record from occupying a
register despite the unnamed bit-field not participating in the record
size nor its alignment.
N.B. This behavior matches GCC and ICC.
llvm-svn: 278656
An __m512 vector type wrapped in a structure should be passed in a
vector register.
Our prior implementation was based on a draft version of the psABI.
This fixes PR28975.
N.B. The update to the ABI was made here:
https://github.com/hjl-tools/x86-psABI/commit/30f9c9
llvm-svn: 278655
This matches the way nvcc encapsulates GPU binaries into host object file.
Now cuobjdump can deal with clang-compiled object files.
Differential Revision: https://reviews.llvm.org/D23429
llvm-svn: 278549
Reapply r278457 with test fixed to not abouse fs case sensitivity.
When the VFS uses a YAML file, the real file path for a
virtual file is described in the "external-contents" field. Example:
...
{
'type': 'file',
'name': 'a.h',
'external-contents': '/a/b/c/a.h'
}
Currently, when parsing umbrella directories, we use
vfs::recursive_directory_iterator to gather the header files to generate the
equivalent modules for. If the external contents for a header does not exist,
we currently are unable to build a module, since the VFS
vfs::recursive_directory_iterator will fail when it finds an entry without a
reliable real path.
Since the YAML file could be prepared ahead of time and shared among
different compiler invocations, an entry might not yet have a reliable
path in 'external-contents', breaking the iteration.
Give the VFS the capability to skip such entries whenever
'ignore-non-existent-contents' property is set in the YAML file.
rdar://problem/27531549
llvm-svn: 278543
This fixes an error in type checking of shift of vector values.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D21678
llvm-svn: 278501
Currently, when trying to evaluate an enable_if condition, we try to
evaluate all arguments a user passes to a function. Given that we can't
use variadic arguments from said condition anyway, not converting them
is a reasonable thing to do. So, this patch makes us ignore any varargs
when attempting to check an enable_if condition.
We'd crash because, in order to convert an argument, we need its
ParmVarDecl. Variadic arguments don't have ParmVarDecls.
llvm-svn: 278471
When the VFS uses a YAML file, the real file path for a
virtual file is described in the "external-contents" field. Example:
...
{
'type': 'file',
'name': 'a.h',
'external-contents': '/a/b/c/a.h'
}
Currently, when parsing umbrella directories, we use
vfs::recursive_directory_iterator to gather the header files to generate the
equivalent modules for. If the external contents for a header does not exist,
we currently are unable to build a module, since the VFS
vfs::recursive_directory_iterator will fail when it finds an entry without a
reliable real path.
Since the YAML file could be prepared ahead of time and shared among
different compiler invocations, an entry might not yet have a reliable
path in 'external-contents', breaking the iteration.
Give the VFS the capability to skip such entries whenever
'ignore-non-existent-contents' property is set in the YAML file.
rdar://problem/27531549
llvm-svn: 278457
Add 'ignore-non-existent-contents' to tell the VFS whether an invalid path
obtained via 'external-contents' should cause iteration on the VFS to stop.
If 'true', the VFS should ignore the entry and continue with the next. Allows
YAML files to be shared across multiple compiler invocations regardless of
prior existent paths in 'external-contents'. This global value is overridable
on a per-file basis.
This adds the parsing and write test part, but use by VFS comes next.
Differential Revision: https://reviews.llvm.org/D23422
rdar://problem/27531549
llvm-svn: 278456
We're only going to provide support for using PIE on architectures that
provide PC-relative addressing. i686 is not one of those, so add the
necessary bits for only passing in -pie -zrelro conditionally.
llvm-svn: 278395
On Linux we pass in -fomit-frame-pointer flags (and similar)
automatically if optimization is enabled. Let's do the same thing on
CloudABI. Without this, Clang seems to run out of registers quite
quickly while trying to build code with inline assembly.
llvm-svn: 278393
Change the retain count checker to treat CoreFoundation-style "CV"-prefixed
reference types from CoreVideo similarly to CoreGraphics types. With this
change, we treat CVFooRetain() on a CVFooRef type as a retain. CVFooRelease()
APIs are annotated as consuming their parameter, so this change prevents false
positives about incorrect decrements of reference counts.
<rdar://problem/27116090>
llvm-svn: 278382
Reapply r277787. For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 278264
CallExpr may have a null direct callee when the callee function is not
known in compile-time. Do not try to take callee name in this case.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23320
llvm-svn: 278238
Summary: When sorting #includes, #include directives that have the same text will be deduplicated when sorting #includes, and only the first #include in the duplicate #includes remains. If the `Cursor` is provided and put on a deleted #include, it will be put on the remaining #include in the duplicate #includes.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D23274
llvm-svn: 278206
constraints were added to _mm256_broadcast_{pd,ps} intel intrinsics.
The spec for these intrinics is ... pretty much silent on alignment.
This is especially frustrating considering the amount of discussion of
alignment in the load and store instrinsics. So I was forced to rely on
the specification for the VBROADCASTF128 instruction.
That instruction's spec is *also* completely silent on alignment.
Fortunately, when it comes to the instruction's spec, silence is enough.
There is no #GP fault option for an underaligned address so this
instruction, and by inference the intrinsic, can read any alignment.
As it happens, the old code worked exactly this way and in fact we have
plenty of code that hands pointers with less than 16-byte alignment to
these intrinsics. This code broke pretty spectacularly with this commit.
Fortunately, the fix is super simple! Change a 16 to a 1, and ta da!
Anyways, a lot of debugging for a really boring fix. =]
llvm-svn: 278202
Summary:
When we emit err_ref_bad_target, we should emit a "'method' declared
here" note. We already do so in most places, just not in
BuildCallToMemberFunction.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23240
llvm-svn: 278195
Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option.
Differential Revision: https://reviews.llvm.org/D22940
llvm-svn: 278155
Adjust target features for amdgcn target when -cl-denorms-are-zero is set.
Denormal support is controlled by feature strings fp32-denormals fp64-denormals in amdgcn target. If -cl-denorms-are-zero is not set and the command line does not set fp32/64-denormals feature string, +fp32-denormals +fp64-denormals will be on for GPU's supporting them.
A new virtual function virtual void TargetInfo::adjustTargetOptions(const CodeGenOptions &CGOpts, TargetOptions &TargetOpts) const is introduced to allow adjusting target option by codegen option.
Differential Revision: https://reviews.llvm.org/D22815
llvm-svn: 278151
Summary: Add test to detect the C++ include paths are passed to both CUDA host and device frontends.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22946
llvm-svn: 278140
It's surprising that you have to pass /Z7 in addition to -gcodeview to
get debug info. The sanitizer runtime, for example, expects that if the
compiler supports the -gline-tables-only flag, then it will emit debug
info.
llvm-svn: 278139
Summary:
Based on a patch by Michael Mueller.
This attribute specifies that a function can be hooked or patched. This
mechanism was originally devised by Microsoft for hotpatching their
binaries (which they're constantly updating to stay ahead of crackers,
script kiddies, and other ne'er-do-wells on the Internet), but it's now
commonly abused by Windows programs that want to hook API functions. It
is for this reason that this attribute was added to GCC--hence the name,
`ms_hook_prologue`.
Depends on D19908.
Reviewers: rnk, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D19909
llvm-svn: 278050
Both -analyze-function and -analyzer-display-progress now share the same
convention for naming functions, which allows discriminating between
methods with the same name in different classes, C++ overloads, and also
presents Objective-C instance and class methods in the convenient notation.
This also allows looking up the name for the particular function you're trying
to restrict analysis to in the -analyzer-display-progress output,
in case it was not instantly obvious.
Differential Revision: https://reviews.llvm.org/D22856
llvm-svn: 278018
This patch (with the corresponding ARM backend patch) adds support for
some new relocation models:
* Read-only position independence (ROPI): Code and read-only data is accessed
PC-relative. The offsets between all code and RO data sections are known at
static link time.
* Read-write position independence (RWPI): Read-write data is accessed relative
to a static base register. The offsets between all writeable data sections
are known at static link time.
These two modes are independent (they specify how different objects
should be addressed), so they can be used individually or together.
These modes are intended for bare-metal systems or systems with small
real-time operating systems. They are designed to avoid the need for a
dynamic linker, the only initialisation required is setting the static
base register to an appropriate value for RWPI code.
There is one C construct not currently supported by these modes: global
variables initialised to the address of another global variable or
function, where that address is not known at static-link time. There are
a few possible ways to solve this:
* Disallow this, and require the user to write their own initialisation
function if they need variables like this.
* Emit dynamic initialisers for these variables in the compiler, called from
the .init_array section (as is currently done for C++ dynamic initialisers).
We have a patch to do this, described in my original RFC email
(http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html), but the
feedback from that RFC thread was that this is not something that belongs in
clang.
* Use a small dynamic loader to fix up these variables, by adding the
difference between the load and execution address of the relevant section.
This would require linker co-operation to generate a table of addresses that
need fixing up.
Differential Revision: https://reviews.llvm.org/D23196
llvm-svn: 278016
This patch adds a command line option to list the checkers that were enabled
by analyzer-checker and not disabled by -analyzer-disable-checker.
It can be very useful to debug long command lines when it is not immediately
apparent which checkers are turned on and which checkers are turned off.
Differential Revision: https://reviews.llvm.org/D23060
llvm-svn: 278006
Dynamic casts are handled relatively well by the static analyzer.
BaseToDerived casts however are treated conservatively. This can cause some
false positives with the NewDeleteLeaks checker.
This patch alters the behavior of BaseToDerived casts. In case a dynamic cast
would succeed use the same semantics. Otherwise fall back to the conservative
approach.
Differential Revision: https://reviews.llvm.org/D23014
llvm-svn: 277989
Bug 1: triples like armv7-pc-linux-musl use the wrong linker name
ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the
subarch field.
Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat"
linker, no matter whether the triple itself mentions "hardfloat".
Patch by Lei Zhang!
Differential Revision: https://reviews.llvm.org/D22904
llvm-svn: 277985
This fixes compiling with headers from the Windows SDK for ARM, where the
YieldProcessor function (in winnt.h) refers to _ARM_BARRIER_ISHST.
The actual MSVC armintr.h contains a lot more definitions, but this is enough to
build code that uses the Windows SDK but doesn't use ARM intrinsics directly.
An alternative would to just keep the addition to intrin.h (to include
armintr.h), but not actually ship armintr.h, instead having clang's intrin.h
include armintr.h from MSVC's include directory. (That one works fine with
clang, at least for building code that uses the Windows SDK.)
Patch by Martin Storsjö!
llvm-svn: 277928
If the return type is a pointer and the function returns the reference to a
pointer, don't warn since only the value is returned, not the reference.
If a reference function parameter appears in the reference chain, don't warn
since binding happens at the caller scope, so addresses returned are not
to local stack. This includes default arguments as well.
llvm-svn: 277889
For builtin logical operators, there is a well-defined ordering of argument
evaluation. For overloaded operator of the same type, there is no argument
evaluation order, similar to other function calls. When both are present,
uninstantiated templates with an operator&& is treated as an unresolved
function call. Unresolved function calls are treated as normal function calls,
and may result in false positives when the builtin logical operator is used.
Have the unsequenced checker ignore dependent expressions to avoid this
false positive. The check also happens in template instantiations to catch
when the overloaded operator is used.
llvm-svn: 277866
For now just disregard the using declaration in this case. Suboptimal,
but wiring up the ability to have declarations of functions that are
separate from their definition (we currently only do that for member
functions) and have differing return types (we don't have any support
for that) is more work than seems reasonable to at least fix this crash.
llvm-svn: 277852
When the type being diffed is a type alias, and the orginal type is not a
templated type, then there will be no unsugared TemplateSpecializationType.
When this happens, exit early from the constructor. Also add assertions to
the other iterator accessor to prevent the iterator from being used.
llvm-svn: 277797
Silence the -Wbitfield-constant-conversion warning for when -1 or other
negative values are assigned to unsigned bitfields, provided that the bitfield
is wider than the minimum number of bits needed to encode the negative value.
llvm-svn: 277796
For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 277787
CloneDetector should be able to detect clones with renamed variables.
However, if variables are referenced multiple times around the code sample,
the usage patterns need to be recognized.
For example, (x < y ? y : x) and (y < x ? y : x) are no longer clones,
however (a < b ? b : a) is still a clone of the former.
Variable patterns are computed and compared during a separate filtering pass.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D22982
llvm-svn: 277757
Summary:
In order to re-define OpenCL built-in functions
'to_{private,local,global}' in OpenCL run-time library LLVM names must
be different from the clang built-in function names.
Reviewers: yaxunl, Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23120
llvm-svn: 277743
Summary:
The append operator on a shell command for quick command-line is
causing trouble on windows. [NFC]
The easiest way to fix them is to avoid using them.
This patch is an attempt to fix this broken build bot:
clang-x86-win2008-selfhost
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9523
Reviewers: rnk
Subscribers: cfe-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23105
llvm-svn: 277576
Fix a crash under -Wthread-safety when finding the destructor for a
lifetime-extending reference.
A patch by Nandor Licker!
Differential Revision: https://reviews.llvm.org/D22419
llvm-svn: 277522
If a target triple is not specified, the default host triple is used,
which is not good for compiling inline assembler code.
Patch by Raphael Isemann!
llvm-svn: 277473
These tests require x86-registered-target, but they don't force the target as
x86 on the command line, which means they will be run and they might fail when
building the x86 backend on another platform (such as AArch64).
Fixes https://llvm.org/bugs/show_bug.cgi?id=28797
Differential Revision: https://reviews.llvm.org/D23054
llvm-svn: 277457
So far the CloneDetector only respected the kind of each statement when
searching for clones. This patch refines the way the CloneDetector collects data
from each statement by providing methods for each statement kind,
that will read the kind-specific attributes.
For example, statements 'a < b' and 'a > b' are no longer considered to be
clones, because they are different in operation code, which is an attribute
specific to the BinaryOperator statement kind.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D22514
llvm-svn: 277449
Use the calling convention of the wrapper directly to set the calling convention
to ensure that the calling convention matches. Incorrectly setting the calling
convention results in the code path being entirely nullified as InstCombine +
SimplifyCFG will prune the mismatched CC calls.
llvm-svn: 277390
The previous change was insufficient to mark the content as read-write as the
structure itself was marked constant. Adjust this and add tests to ensure that
the section is marked appropriately as being read-write.
llvm-svn: 277200
Adding extension cl_khr_mipmap_image to clang's OpenCL Extensions and initiated inside AMDGPU Target.
Patch by Aaron En Ye Shi.
Differential Revision: https://reviews.llvm.org/D22637
llvm-svn: 277181
As reported in bug 28473, GCC supports "final" functionality in pre-C++11 code using the __final keyword. Clang currently supports the "final" keyword in accordance with the C++11 specification, however it ALSO supports it in pre-C++11 mode, with a warning.
This patch adds the "__final" keyword for compatibility with GCC in GCC Keywords mode (so it is enabled with existing flags), and issues a warning on its usage (suggesting switching to the C++11 keyword). This patch also adds a regression test for the functionality described. I believe this patch has minimal impact, as it simply adds a new keyword for existing behavior.
This has been validated with check-clang to avoid regressions. Patch is created in reference to revisions 276665.
Patch by Erich Keane.
Differential Revision: https://reviews.llvm.org/D22919
llvm-svn: 277134
This means that a function marked with an availability attribute can safely
refer to a declaration that is greater than the deployment target, but less then
or equal to the context availability without -Wpartial-availability firing.
Differential revision: https://reviews.llvm.org/D22697
llvm-svn: 277058
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
Summary:
This patch prevents OpenMP flags from being forwarded to CUDA device commands. That was causing the CUDA frontend to attempt to emit OpenMP code which is not supported.
This fixes the bug reported in https://llvm.org/bugs/show_bug.cgi?id=28723.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, tra, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22895
llvm-svn: 276979
Summary: This patch adds support for the is_device_ptr clause. It expands SEMA to use the mappable expression logic that can only be tested with code generation in place and check conflicts with other data sharing related clauses using the mappable expressions infrastructure.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22788
llvm-svn: 276978
Summary: This patch adds support for the use_device_ptr clause. It includes changes in SEMA that could not be tested without codegen, namely, the use of the first private logic and mappable expressions support.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22691
llvm-svn: 276977
Summary: This patch add support to map pointers through references in class members. Although a reference does not have storage that a user can access, it still has to be mapped in order to get the deep copy right and the dereferencing code work properly.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22787
llvm-svn: 276934
Summary:
This patch fixes a bug in the map of array sections whose base is a reference to a pointer. The existing mapping support was not prepared to deal with it, causing the compiler to crash.
Mapping a reference to a pointer enjoys the same characteristics of a regular pointer, i.e., it is passed by value. Therefore, the reference has to be materialized in the target region.
Reviewers: hfinkel, carlo.bertolli, kkwli0, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22690
llvm-svn: 276933
Summary:
This patch aims at removing redundancy in the way include paths for the regular and offloading toolchains are appended to the arguments list in the clang tool.
This was suggested by @rsmith in response to r275931.
Reviewers: rsmith, tra
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22518
llvm-svn: 276929
Summary:
Before this patch, we computed the offsets in memory of args passed to
GPU kernel functions by throwing all of the args into an LLVM struct.
clang emits packed llvm structs basically whenever it feels like it, and
packed structs have alignment 1. So we cannot rely on the llvm type's
alignment matching the C++ type's alignment.
This patch fixes our codegen so we always respect the clang types'
alignments.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D22879
llvm-svn: 276927
Summary:
Previously this crashed inside EmitThisParam(). There should be no
prelude for naked functions, so just skip the whole thing.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22715
llvm-svn: 276925
Summary:
In RenderScript, the size of the argument or return value emitted in the
IR is expected to be the same as the size of corresponding qualified
type. For ARM and AArch64, the coercion performed by Clang can
change the parameter or return value to a type whose size is different
(usually larger) than the original aggregate type. Specifically, this
can happen in the following cases:
- Aggregate parameters of size <= 64 bytes and return values smaller
than 4 bytes on ARM
- Aggregate parameters and return values smaller than bytes on
AArch64
This patch coerces the cases above to an integer array that is the same
size and alignment as the original aggregate. A new field is added to
TargetInfo to detect a RenderScript target and limit this coercion just
to that case.
Tests added to test/CodeGen/renderscript.c
Reviewers: rsmith
Subscribers: aemerson, srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D22822
llvm-svn: 276904
This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru
which we can specify a default value for -rtlib (libgcc or
compiler-rt) at build time, just like how we set the default C++
stdlib thru CLANG_DEFAULT_CXX_STDLIB.
With these two options, we can configure clang to build binaries on
Linux that have no runtime dependence on any gcc libs (libstdc++ or
libgcc_s).
Patch by Lei Zhang!
Differential Revision: https://reviews.llvm.org/D22663
llvm-svn: 276848
This patch adds the CloneDetector class which allows searching source code
for clones.
For every statement or group of statements within a compound statement,
CloneDetector computes a hash value, and finds clones by detecting
identical hash values.
This initial patch only provides a simple hashing mechanism
that hashes the kind of each sub-statement.
This patch also adds CloneChecker - a simple static analyzer checker
that uses CloneDetector to report copy-pasted code.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D20795
llvm-svn: 276782
With PCH+Module, sometimes compiler gives a hard error:
Module file ‘<some-file path>.pcm' is out of date and needs to be rebuilt
This happens when we have a pch importing a module and the module gets
overwritten by another compiler instance after we build the pch (one example is
that both compiler instances hash to the same pcm file but use different
diagnostic options). When we try to load the pch later on, the compiler notices
that the imported module is out of date (modification date, size do not match)
but it can't handle this out of date pcm (i.e it does not know how to rebuild
the pch).
This commit introduces a new command line option so for PCH + module, we can
turn on this option and if two compiler instances only differ in diagnostic
options, the latter instance will not invalidate the original pcm.
rdar://26675801
Differential Revision: http://reviews.llvm.org/D22773
llvm-svn: 276769
The OpenMP spec mandates that 'a teams construct must be contained within a
target construct'. Currently, this scenario is not diagnosed. This patch is
to add check for orphaned teams construct and issue an error message.
Differential Revision: https://reviews.llvm.org/D22785
llvm-svn: 276726
After r275121, we stopped mapping regions from system headers. Lambdas
declared in regions belonging to system headers started producing empty
coverage mappings, since the files corresponding to their spelling locs
were being ignored.
The coverage reader doesn't know what to do with these empty mappings.
This commit makes sure that we don't produce them and adds a test. I'll
make the reader stricter in a follow-up commit.
llvm-svn: 276716
on the nullabilities of its operands.
This commit is a follow-up to r276076 and enables
computeConditionalNullability to compute the merged nullability when
the operands are objective-c pointers.
rdar://problem/22074116
llvm-svn: 276696
The '#pragma once' directive was erroneously ignored when encountered
in the header-file specified in generate-PCH-mode. This resulted in
compile-time errors in some cases with legal code, and also a misleading
warning being produced.
Patch by Warren Ristow!
Differential Revision: http://reviews.llvm.org/D19815
llvm-svn: 276653
Additionally, for pre-C++1z, instead of forbidding a lambda's closure type from being a literal type through circumlocutorily setting HasNonLiteralTypeFieldsOrBases falsely to true -- handle lambda's more directly in CXXRecordDecl::isLiteral().
One additional small step towards implementing constexpr-lambdas.
Thanks to Richard Smith for his review!
https://reviews.llvm.org/D22662
llvm-svn: 276514
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
Processing update records (and loading a module, in general) might trigger
unexpected calls to the ASTWriter (being a mutation listener). Now we have a
mechanism to suppress those calls to the ASTWriter but notify other possible
mutation listeners.
Fixes https://llvm.org/bugs/show_bug.cgi?id=28332
Patch by Cristina Cristescu and me.
Reviewed by Richard Smith (D21800).
llvm-svn: 276473
Summary:
This patch enables .rgba accessors to ext_vector_type types and adds
tests for syntax validation and code generation.
'a' and 'b' can appear either in the point access mode or the numeric
access mode (for indices 10 and 11). To disambiguate between the two
usages, the accessor type is explicitly passed to relevant methods.
Reviewers: rsmith
Subscribers: Anastasia, bader, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D20602
llvm-svn: 276455
This change depends on the corresponding LLVM change at:
https://reviews.llvm.org/D22519
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address
space.
With this LLVM change, these intrinsics are overloaded for any adddress space
for memory objects and we can use these llvm invariant intrinsics in
non-default address spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant
memory in managed languages.
llvm-svn: 276448
As discussed on D22460, I've updated the vbroadcastf128 pd256/ps256 builtins to map directly to generic IR - load+splat a 128-bit vector to both lanes of a 256-bit vector.
Fix for PR28657.
llvm-svn: 276417
The builder prints out the following IR:
\5CCoverageMapping\5COutput\5Ctest\5Cf1.c
The updated test in r276367 expects path separators to be either '/' or
'\\', so it chokes on the unexpected "5C" stuff. I'm not sure what that
is, but I included a kludge that should work around it.
Failing bot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/8718
llvm-svn: 276370
We should be able to use `mkdir` without turning on `REQUIRES: shell`.
Moreover, this test should check for a path separator which precedes the
relative filename to make sure that absolute paths are being used.
llvm-svn: 276367
This checker checks copy and move assignment operators whether they are
protected against self-assignment. Since C++ core guidelines discourages
explicit checking for `&rhs==this` in general we take a different approach: in
top-frame analysis we branch the exploded graph for two cases, where &rhs==this
and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of the
work. It is important that we check all copy and move assignment operator in top
frame even if we checked them already since self-assignments may happen
undetected even in the same translation unit (e.g. using random indices for an
array what may or may not be the same).
This reapplies r275820 after fixing a string-lifetime issue discovered by the
bots.
A patch by Ádám Balogh!
Differential Revision: https://reviews.llvm.org/D19311
llvm-svn: 276365
rewriteBuiltinFunctionDecl can encounter errors when performing
DefaultFunctionArrayLvalueConversion. These errors were not handled
which led to a null pointer dereference.
This fixes PR28651.
llvm-svn: 276352
Patch broke ModuleDebugInfo test on the build bots (but not locally). Again.
svn revision: r276271
This reverts commit 9da8a1b05362bc96f2855fb32b5588b89407685d.
llvm-svn: 276279
Unreferenced nested structs and classes were omitted from the debug info. In DWARF, this was intentional, to avoid bloat. But for CodeView, we want this information to be consistent with what Microsoft tools would produce and expect.
llvm-svn: 276271
In atomic builtins, we assumed that the LValue conversion on the first
argument would succeed. So, we would crash given code like:
```
void ovl(char);
void ovl(int);
__atomic_store_n(ovl, 0, 0);
```
This patch makes us not assume that said conversion is successful. :)
llvm-svn: 276232
OpenMP 4.5 removed the restriction that array section lower bound must be non negative.
This change is to allow negative values for array section based on pointers.
For array section based on array type there is still a restriction: "The array section must be a subset of the original array."
Patch by David S.
Differential Revision: https://reviews.llvm.org/D22481
llvm-svn: 276177
Clang misdiagnoses atomic captures cases that contains parens.
i.e.
int v, int *p;
#pragma omp atomic capture
{ v = (*p); (*p)++; }
Patch by David S.
Differential Revision: https://reviews.llvm.org/D22487
llvm-svn: 276167
Allows AMDGCN target to generate images (such as %opencl.image2d_t) in constant address space.
Images will still be generated in global address space by default.
Added tests to existing opencl-types.cl in test\CodeGenOpenCL.
Patch by Aaron En Ye Shi.
Differential Revision: https://reviews.llvm.org/D22523
llvm-svn: 276161
we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported. The initializer step for a module
then recursively initializes modules that its own headers imported.
For example, this avoids running the <iostream> global initializer in programs
that don't actually use iostreams, but do use other parts of the standard
library.
llvm-svn: 276159
D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead.
It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match).
This patch changes both scalar and packed versions back to using x86-specific builtins.
It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding.
Differential Revision: https://reviews.llvm.org/D22105
llvm-svn: 276102
nullabilities of its operands.
This patch defines a function to compute the nullability of conditional
expressions, which enables Sema to precisely detect implicit conversions
of nullable conditional expressions to nonnull pointers.
rdar://problem/25166556
Differential Revision: https://reviews.llvm.org/D22392
llvm-svn: 276076
Sema actions on ObjCDictionaryLiteral and ObjCArryLiteral are currently
done as a side-effect of Sema upon parent expressions, which incurs of
delayed typo corrections for such literals to be performed by TypoTransforms
upon the ObjCDictionaryLiteral and ObjCArryLiteral themselves instead of
its elements individually.
This is specially bad because it was not designed to act on several
elements; searching through all possible combinations of corrections for
several elements is very expensive. Additionally, when one of the
elements has no correction candidate, we still explore all options and
at the end emit no typo corrections whatsoever.
Do the proper sema actions by acting on each element alone during appropriate
literal parsing time to get proper diagonistics and decent compile time
behavior.
Differential Revision: http://reviews.llvm.org/D22183
rdar://problem/21046678
llvm-svn: 276020
Added the opencl.ocl.version metadata to be emitted with amdgcn. Created a static function emitOCLVerMD which is shared between triple spir and target amdgcn.
Also added new testcases to existing test file, spir_version.cl inside test/CodeGenOpenCL.
Patch by Aaron En Ye Shi.
Differential Revision: https://reviews.llvm.org/D22424
llvm-svn: 276010
It's a patch for PR28050. Seems like overloading resolution wipes out
the first standard conversion sequence (before user-defined conversion)
in case of deprecated string literal conversion.
Differential revision: https://reviews.llvm.org/D21228
Patch by Alexander Makarov
llvm-svn: 275970
Summary:
N32 and N64 follow the standard ELF conventions (.L) whereas O32 uses its own
($).
This fixes the majority of object differences between -fintegrated-as and
-fno-integrated-as.
Reviewers: sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: https://reviews.llvm.org/D22412
llvm-svn: 275967
Having the following code pattern will result in incorrect diagnostic
int main() {
int arr[10];
#pragma omp target data map(arr[:])
#pragma omp target map(arr)
{}
}
t.cpp:4:24: error: original storage of expression in data environment is shared
but data environment do not fully contain mapped expression storage
#pragma omp target map(arr)
^~~
t.cpp:3:29: note: used here
#pragma omp target data map(arr[:])
^~~~~~
1 error generated.
Patch by David S.
Differential Revision: https://reviews.llvm.org/D22075
llvm-svn: 275926
This fixes the issue of having duplicate entries for the same file in a
coverage report s.t none of the entries actually displayed the correct
coverage information.
llvm-svn: 275913
Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.
Differential Revision: https://reviews.llvm.org/D22248
rdar://problem/12907612
llvm-svn: 275907
For assembly files without .intel_syntax or .att_syntax directives, allow the
-masm= flag to supply a default assembly dialect. For example,
C:\TMP> type intel.s
.text
mov al,0
C:\TMP> clang -masm=intel -c intel.s
Without this patch, one would need to pass an "-mllvm -x86-asm-syntax=" flag
directly to the backend.
C:\TMP> clang -mllvm --x86-asm-syntax=intel -c intel.s
Differentials Review: http://reviews.llvm.org/D22285
llvm-svn: 275877
This checker checks copy and move assignment operators whether they are
protected against self-assignment. Since C++ core guidelines discourages
explicit checking for `&rhs==this` in general we take a different approach: in
top-frame analysis we branch the exploded graph for two cases, where &rhs==this
and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of the
work. It is important that we check all copy and move assignment operator in top
frame even if we checked them already since self-assignments may happen
undetected even in the same translation unit (e.g. using random indices for an
array what may or may not be the same).
A patch by Ádám Balogh!
Differential Revision: https://reviews.llvm.org/D19311
llvm-svn: 275820
target_parallel_for_simd_collapse_messages.cpp and target_parallel_for_simd_ordered_messages.cpp give different diagnostic messages in compiling with -std=c++11. The test cases are updated to make it compatible.
Differential Revision: https://reviews.llvm.org/D22417
llvm-svn: 275805
This reverts also r275029, "Update Clang tests after adding inference for the returned argument attribute"
It broke LTO build. Seems miscompilation.
llvm-svn: 275756
The test was relying on the default triple which may not be correct. Explicitly
provide it a triple. Should repair the windows on Linux builder.
llvm-svn: 275738
Add support for ObjC types to respect the DLLImport/DLLExport storage
annotations. This only effects COFF output. This would allow usage with
clang/C2, but not with clang/LLVM due to hard coded section names.
llvm-svn: 275737
This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the
Parser and Sema to generate it. This node represents an availability check of
the form:
@available(macos 10.10, *);
Which will eventually compile to a runtime check of the host's OS version. This
is the first patch of the feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential Revision: https://reviews.llvm.org/D22171
llvm-svn: 275654
Summary:
This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.
This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.
This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)
```
0: input, "cudatests.cu", cuda, (host-cuda)
1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
2: compiler, {1}, ir, (host-cuda)
3: input, "cudatests.cu", cuda, (device-cuda, sm_35)
4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)
5: compiler, {4}, ir, (device-cuda, sm_35)
6: backend, {5}, assembler, (device-cuda, sm_35)
7: assembler, {6}, object, (device-cuda, sm_35)
8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object
9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler
10: input, "cudatests.cu", cuda, (device-cuda, sm_37)
11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)
12: compiler, {11}, ir, (device-cuda, sm_37)
13: backend, {12}, assembler, (device-cuda, sm_37)
14: assembler, {13}, object, (device-cuda, sm_37)
15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object
16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler
17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)
18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir
19: backend, {18}, assembler
20: assembler, {19}, object
21: input, "cuda", object
22: input, "cudart", object
23: linker, {20, 21, 22}, image
```
The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.
Reviewers: echristo, hfinkel, jlebar, ABataev, tra
Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18171
llvm-svn: 275645
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
Extend the __declspec(dll*) attribute to cover ObjC interfaces. This was
requested by Microsoft for their ObjC support. Cover both import and export.
This only adds the semantic analysis portion of the support, code-generation
still remains outstanding. Add some basic initial documentation on the
attributes that were previously empty. Tweak the previous tests to use the
relative expected-warnings to make the tests easier to read.
llvm-svn: 275610
This patch adds the check for specifying both simdlen and safelen clauses on the 'distribute simd' or 'distribute parallel for simd' constructs.
Differential Revision: https://reviews.llvm.org/D22384
llvm-svn: 275529
Richard Smith