Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
instantiation is in a module.
This patch fixes the condition for determining whether the debug info for a
template instantiation will exist in an imported clang module by:
- checking whether the ClassTemplateSpecializationDecl is complete and
- checking that the instantiation was in a module by looking at the first field.
I also added a negative check to make sure that a typedef to a forward-declared
template (with the definition outside of the module) is handled correctly.
http://reviews.llvm.org/D19443
rdar://problem/25553724
llvm-svn: 267464
Currently, the UBSan docs make it sound like the object-size sanitizer
will only detect out-of-bounds reads/writes. It also catches some
operations that don't necessarily access memory (invalid downcasts,
calls of methods on invalid pointers, ...). This patch adds a note
about this behavior in the docs.
llvm-svn: 267447
Summary:
After applying replacements, redundant code like extra commas or empty namespaces
might be introduced. Fixer can detect and remove any redundant code introduced by replacements.
The current implementation only handles redundant commas.
Reviewers: djasper, klimek
Subscribers: ioeric, mprobst, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D18551
llvm-svn: 267416
If an address of a field is passed through a const pointer,
the whole structure's base region should receive the
TK_PreserveContents trait and avoid invalidation.
Additionally, include a few FIXME tests shown up during testing.
Differential Revision: http://reviews.llvm.org/D19057
llvm-svn: 267413
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
LLVM really wants a debug location on every inlinable call in a function
with debug info, because it otherwise cannot set up inlining debug info.
This change applies an artificial line 0 debug location (which is how
DWARF marks automatically generated code that has no corresponding
source code) to the .__kmpc_global_dtor_. functions to avoid the
LLVM Verifier complaining.
llvm-svn: 267369
We should just test the effect of the clang level option here, i.e.
that a summary is correctly emitted with -flto=thin
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267321
LLVM stopped using MDString-based type references, and DIBuilder no
longer fills 'retainedTypes:' with every DICompositeType that has an
'identifier:' field. There are just minor changes to keep the same
behaviour in CFE.
Leaving 'retainedTypes:' unfilled has a dramatic impact on the output
order of the IR though. There are a huge number of testcase changes,
which were unfortunately not really scriptable.
llvm-svn: 267297
Remove the floating point to bool conversion warnings. Some of these
conversions will be caught by -Wliteral-conversion and -Wfloat-conversion
llvm-svn: 267234
Write out the PGOFuncName meta data if PGOFuncName is different from function's
raw name. This should only apply to internal linkage functions. This is to be
consumed by indirect-call promotion when called in LTO optimization pass.
Differential Revision: http://reviews.llvm.org/D18624
llvm-svn: 267224
For various reasons, involving dllexport and class linkage compuations,
we have to wait until after the semicolon after a class declaration to
emit inline methods. These are "deferred" decls. Before this change,
finishing the tag decl would trigger us to deserialize some PCH so that
we could make a "pretty" IR-level type. Deserializing the PCH triggered
calls to HandleTopLevelDecl, which, when done, checked the deferred decl
list, and emitted some dllexported decls that weren't ready.
Avoid this re-entrancy. Deferred decls should not get emitted when a tag
is finished, they should only be emitted after a real top level decl in
the main file.
llvm-svn: 267186
causes code generation failure.
The codegen part of firstprivate clause for member decls used type of
original variable without skipping reference type from
OMPCapturedExprDecl. Patch fixes this problem.
llvm-svn: 267125
If loop control variable for simd-based directives is explicitly marked
as linear/lastprivate in clauses, codegen for such construct would
crash. Patch fixes this problem.
llvm-svn: 267101
Since r265060 LLVM infers correct __nvvm_reflect attributes, so
explicit declaration of __nvvm_reflect() is no longer needed.
Differential Revision: http://reviews.llvm.org/D19074
llvm-svn: 267062
Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19169
llvm-svn: 267059
Restructure the implict floating point to integer conversions so that
interesting sub-groups are under different flags. Breakdown of warnings:
No warning:
Exact conversions from floating point to integer:
int x = 10.0;
int x = 1e10;
-Wliteral-conversion - Floating point literal to integer with rounding:
int x = 5.5;
int x = -3.4;
-Wfloat-conversion - All conversions not covered by the above two:
int x = GetFloat();
int x = 5.5 + 3.5;
-Wfloat-zero-conversion - The expression converted has a non-zero floating
point value that gets converted to a zero integer value, excluded the cases
falling under -Wliteral-conversion. Subset of -Wfloat-conversion.
int x = 1.0 / 2.0;
-Wfloat-overflow-conversion - The floating point value is outside the range
of the integer type, exluding cases from -Wliteral conversion. Subset of
-Wfloat-conversion.
char x = 500;
char x = -1000;
-Wfloat-bool-conversion - Any conversion of a floating point type to bool.
Subset of -Wfloat-conversion.
if (GetFloat()) {}
bool x = 5.0;
-Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable
floating point value to bool. Subset of -Wfloat-bool-conversion.
bool x = 1.0;
bool x = 4.0 / 20.0;
Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for
floating point values.
llvm-svn: 267054
This allows using a different standard library (the one from argv[0] in
the compilation database) with the correct builtins.
Differential Revision: http://reviews.llvm.org/D19356
llvm-svn: 266973
xmmintrin.h a bit more directed. If for whatever reason modules are enabled but
we textually include one of these headers, don't deploy the special case for
modules. To make this work cleanly, extend __building_module to be defined
even when modules is disabled.
llvm-svn: 266945
We kept this around for a while since Xcode 6 and earlier had a build
setting for this warning. It was removed in Xcode 7 so there should be
no need for this warning now.
llvm-svn: 266938
in the compile unit that contains their implementation even if their
interface is declared in a module.
The private @implementation of an @interface may have additional
hidden ivars so we should not defer to the public version of the
type that is found in the module.
<rdar://problem/25541798>
llvm-svn: 266937
If the untied clause is present on a task construct, any thread in the
team can resume the task region after a suspension. Patch adds proper
codegen for untied tasks.
llvm-svn: 266853
Summary:
This is a follow-on to apply Duncan's new DIType ODR uniquing from
r266549 and r266713 in more places.
When invoking ThinLTO backend compiles via clang (for a distributed
build), invoke enableDebugTypeODRUniquing() before parsing the module.
Reviewers: dexonsmith, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D19264
llvm-svn: 266852
Summary:
https://llvm.org/bugs/show_bug.cgi?id=27396
This fixes an issue in response files where "\r\n" was being interpreted
as two EOL markers (i.e. we consumed the '\r' as terminating the
previous token, and then parsed the '\n' as a significant EOL). This
breaks response files where joined arguments get split across multiple
lines (like "-x\r\nc"). I also fixed an accidental issue in the
response-file.c test, where the response file is appended to, instead of
being overwritten.
Reviewers: rnk
Subscribers: danalbert, llvm-commits
Differential Revision: http://reviews.llvm.org/D19289
llvm-svn: 266840
A subsequent patch will propose a "distribute" loop hint. Similarly to
unroll, this does not have a "assume_safety" argument either so this
condition will get more complex.
llvm-svn: 266827
The intrinsic is now called llvm.thread.pointer, not
llvm.aarch64.thread.pointer. Also, the code handling it in CGBuiltin.cpp
is dead - it's already covered by GCCBuiltin. Remove it.
Differential Revision: http://reviews.llvm.org/D19099
llvm-svn: 266817
This patch changes the default DWARF version for cc1as from invalid 0 to 2,
which should be the lowest common denominator on all platforms.
rdar://problem/24735813
llvm-svn: 266814
r259537 added vfma/vfms to armv7, but the builtin was only lowered
on the AArch64 side. Instead of supporting it on ARM, get rid of it.
The vfms builtin lowered to:
%nb = fsub float -0.0, %b
%r = @llvm.fma.f32(%a, %nb, %c)
Instead, define the operation in terms of vfma, and swap the
multiplicands. It now lowers to:
%na = fsub float -0.0, %a
%r = @llvm.fma.f32(%na, %b, %c)
This matches the instruction more closely, and lets current LLVM
generate the "natural" operand ordering:
fmls.2s v0, v1, v2
instead of the crooked (but equivalent):
fmls.2s v0, v2, v1
Except for theses changes, assembly is identical.
LLVM accepts both commutations, and the LLVM tests in:
test/CodeGen/AArch64/arm64-fmadd.ll
test/CodeGen/AArch64/fp-dp3.ll
test/CodeGen/AArch64/neon-fma.ll
test/CodeGen/ARM/fusedMAC.ll
already check either the new one only, or both.
Also verified against the test-suite unittests.
llvm-svn: 266807
Summary: When there are comments in the line, one token may be checked multiple times.
Reviewers: mprobst, djasper
Subscribers: ioeric, cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19106
llvm-svn: 266803
Summary:
`interface` can be used as a fee standing identifier in JavaScript/TypeScript.
This change uses the heuristic of whether it's followed by another identifier
as an indication.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19240
llvm-svn: 266789
Currently, for the ppc64--gnu and aarch64 ABIs, we recognize:
typedef __attribute__((__ext_vector_type__(3))) float v3f32;
typedef __attribute__((__ext_vector_type__(16))) char v16i8;
struct HFA {
v3f32 a;
v16i8 b;
};
as an HFA. Since the first type encountered is used as the base type,
we pass the HFA as:
[2 x <3 x float>]
Which leads to incorrect IR (relying on padding values) when the
second field is used.
Instead, explicitly widen the vector (after size rounding) in
isHomogeneousAggregate.
Differential Revision: http://reviews.llvm.org/D18998
llvm-svn: 266784
If the untied clause is present on a task construct, any thread in the
team can resume the task region after a suspension. Patch adds proper
codegen for untied tasks.
llvm-svn: 266754
Summary:
Prevent hasAncestor from comparing nodes that are not supported.
hasDescendant was fixed some time ago to avoid this problem.
I'm applying the same fix to hasAncestor: if any object in the Builder map is
not comparable, skip the cache.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19231
llvm-svn: 266748
Summary:
Change `import` and `export` parsing to special case the renaming
syntax (`import x, {y as bar} ...`, `export {x}`) and otherwise just
parse a regular structural element.
This simplifies the code a bit and should be more correct - it's easier
to recognise the specific import syntax than to recognise arbitrary
expressions and declarations.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19242
llvm-svn: 266743
If the untied clause is present on a task construct, any thread in the team can resume the task region after a suspension. Patch adds proper codegen for untied tasks.
llvm-svn: 266722
With this patch compiler emits warning if it tries to make implicit instantiation
of a template but cannot find the template definition. The warning can be suppressed
by explicit instantiation declaration or by command line options
-Wundefined-var-template and -Wundefined-func-template. The implementation follows
the discussion of http://reviews.llvm.org/D12326.
Differential Revision: http://reviews.llvm.org/D16396
llvm-svn: 266719
Summary:
This completes the flag's tristate, letting you override it at will on
the command line.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D19248
llvm-svn: 266707
doesn't warn if it's passed to a link action. This matches the behavior for
most other compilation-only options (including things like -f flags), and is
necessary to suppress warnings on systems like cmake that always pass all
compile flags to the linker.
llvm-svn: 266695
The builtins already exist in LLVM, but are not exposed to the C/C++
programmers. This patch adds all the information about the builtins
needed for clang, as well as a test for all available intrinsics.
llvm-svn: 266671
return type.
Emit a warning instead of crashing in IR generation.
rdar://22762981
Differential Revision: http://reviews.llvm.org/D18567
llvm-svn: 266648
constructor's definition is in an implementation block.
Without this commit, ptr doesn't get initialized to null in the
following code:
struct S {
S();
void *ptr = nullptr;
};
@implementation I
S::S() {}
@end
rdar://problem/25693624
llvm-svn: 266645
template<class T> void f(T) = delete;
template<> void f(int); // OK.
f(3); // OK
Implementation strategy:
When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.
The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted).
The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.
I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution. But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path. Hopefully it'll prove to not be a bad choice.
llvm-svn: 266561
Since elements of most kinds of DICompositeType have back references,
most are involved in uniquing cycles. Except via the ODR 'identifier:'
field, which doesn't care about the storage type (see r266549),
they have no hope of being uniqued.
Distinct nodes are far more efficient, so use them for most kinds of
DICompositeType definitions (i.e., when DIType::isForwardDecl is false).
The exceptions:
- DW_TAG_array_type, since their elements never have back-references
and they never have ODR 'identifier:' fields;
- DW_TAG_enumeration_type when there is no ODR 'identifier:' field,
since their elements usually don't have back-references.
This breaks the last major uniquing cycle I'm aware of in the debug info
graph. The impact won't be enormous for C++ because references to
ODR-uniqued nodes still use string-based DITypeRefs; but this should
prevent a regression in C++ when we drop the string-based references.
This wouldn't have been reasonable until r266549, when composite types
stopped relying on being uniqued by structural equivalence to prevent
blow-ups at LTO time.
llvm-svn: 266556
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266516
Summary:
Without this change, we silently proceed on without including
__clang_cuda_runtime_wrapper.h. This leads to very strange behavior --
you say you're compiling CUDA code, but e.g. __device__ is not defined!
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19180
llvm-svn: 266496
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
llvm-svn: 266415
For example, "cl.exe a.c /linkfoo bar" is a valid invocation and
forwards "foo" and "bar" to link.exe. This makes clang-cl handle
that kind of invocation.
Depends on LLVM r266394.
llvm-svn: 266395
Indentation of the last line was reset to the initial indentation of the block when reaching EOF.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19065
llvm-svn: 266321
Including VirtualFileSystem.h in the clangFormat.h indirectly includes <atomic>.
This header is blocked when compiling with /clr.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19064
llvm-svn: 266319
The example below should work identically with and without compiler native
wchar_t support.
void foo(wchar_t * t = L"");
Differential Revision: http://reviews.llvm.org/D19056
llvm-svn: 266287
Summary:
AllKindInfo is being indexed by NodeKindId, so the order must match.
Extended ASTTypeTraits tests to cover this.
Reviewers: sbenza
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19059
llvm-svn: 266268
a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_BASE_SPECIFIERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266266
r265877 tries to put methods that are deprecated or unavailable to the
front of the global pool to emit diagnostics, but it breaks some of
our existing codes that depend on choosing a certain method for id
lookup.
This commit orders the methods with the same declaration with respect
to the availability, but do not order methods with different declaration.
rdar://25707511
llvm-svn: 266264
Non-owning pointers that cache LLVM types and constants can use
'nullptr' default member initializers so that we don't need to mention
them in the constructor initializer list.
Owning pointers should use std::unique_ptr so that we don't need to
manually delete them in the destructor. They also don't need to be
mentioned in the constructor at that point.
NFC
llvm-svn: 266263
of a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_CTOR_INITIALIZERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266254
Under certain conditions clang currently fails to properly diagnostic ObjectC
parameter list when type args and protocols are mixed in the same list. This
happens when the first item in the parameter list is a (1) protocol, (2)
unknown type or (3) a list of protocols/unknown types up to the first type
argument. Fix the problem to report the proper error, example:
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
NSNumber *bar = foo[0];
NSLog(@"%@", bar);
$ clang ...
x.m:7:13: error: angle brackets contain both a type ('NSValue') and a protocol ('M')
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
~ ^
Differential Revision: http://reviews.llvm.org/D18997
rdar://problem/22204367
llvm-svn: 266245
George Burgess IV