After mailing list discussion on 11-13 March we would prefer to stick to a
single spelling of the long option.
This reverts commit 30035fe1a7c759c89ee62eb46efce6b3790fcc08.
llvm-svn: 237003
Summary:
Possible coverage levels are:
* -fsanitize-coverage=func - function-level coverage
* -fsanitize-coverage=bb - basic-block-level coverage
* -fsanitize-coverage=edge - edge-level coverage
Extra features are:
* -fsanitize-coverage=indirect-calls - coverage for indirect calls
* -fsanitize-coverage=trace-bb - tracing for basic blocks
* -fsanitize-coverage=trace-cmp - tracing for cmp instructions
* -fsanitize-coverage=8bit-counters - frequency counters
Levels and features can be combined in comma-separated list, and
can be disabled by subsequent -fno-sanitize-coverage= flags, e.g.:
-fsanitize-coverage=bb,trace-bb,8bit-counters -fno-sanitize-coverage=trace-bb
is equivalient to:
-fsanitize-coverage=bb,8bit-counters
Original semantics of -fsanitize-coverage flag is preserved:
* -fsanitize-coverage=0 disables the coverage
* -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func
* -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb
* -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge
* -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls
Driver tries to diagnose invalid flag usage, in particular:
* At most one level (func,bb,edge) must be specified.
* "trace-bb" and "8bit-counters" features require some level to be specified.
See test case for more examples.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9577
llvm-svn: 236790
- added -fcuda-include-gpubinary option to incorporate results of
device-side compilation into host-side one.
- generate code to register GPU binaries and associated kernels
with CUDA runtime and clean-up on exit.
- added test case for init/deinit code generation.
Differential Revision: http://reviews.llvm.org/D9507
llvm-svn: 236765
A LambdaCapture does not have sufficient information
to correctly determine whether it is an init-capture or not.
Doing so requires knowledge held in the LambdaExpr itself.
It the case of a nested capture of an init-capture it is not
sufficient to check (as LambdaCapture::isInitCapture did)
whether the associated VarDecl was from an init-capture.
This patch moves isInitCapture to LambdaExpr and updates
Capture->isInitCapture() to Lambda->isInitCapture(Capture).
llvm-svn: 236760
Summary:
The next step is to add user-friendly control over these options
to driver via -fsanitize-coverage= option.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9545
llvm-svn: 236756
The MSVC 2015 ABI utilizes a rather straightforward adaptation of the
algorithm found in the appendix of N2382. While we are here, implement
support for emitting cleanups if an exception is thrown while we are
intitializing a static local variable.
llvm-svn: 236697
This adds low-level builtins to allow access to all of the z13 vector
instructions. Note that instructions whose semantics can be described
by standard C (including clang extensions) do not get any builtins.
For each instructions whose semantics *cannot* (fully) be described, we
define a builtin named __builtin_s390_<insn> that directly maps to this
instruction. These are intended to be compatible with GCC.
For instructions that also set the condition code, the builtin will take
an extra argument of type "int *" at the end. The integer pointed to by
this argument will be set to the post-instruction CC value.
For many instructions, the low-level builtin is mapped to the corresponding
LLVM IR intrinsic. However, a number of instructions can be represented
in standard LLVM IR without requiring use of a target intrinsic.
Some instructions require immediate integer operands within a certain
range. Those are verified at the Sema level.
Based on a patch by Richard Sandiford.
llvm-svn: 236532
This patch adds support for the z13 architecture type. For compatibility
with GCC, a pair of options -mvx / -mno-vx can be used to selectively
enable/disable use of the vector facility.
When the vector facility is present, we default to the new vector ABI.
This is characterized by two major differences:
- Vector types are passed/returned in vector registers
(except for unnamed arguments of a variable-argument list function).
- Vector types are at most 8-byte aligned.
The reason for the choice of 8-byte vector alignment is that the hardware
is able to efficiently load vectors at 8-byte alignment, and the ABI only
guarantees 8-byte alignment of the stack pointer, so requiring any higher
alignment for vectors would require dynamic stack re-alignment code.
However, for compatibility with old code that may use vector types, when
*not* using the vector facility, the old alignment rules (vector types
are naturally aligned) remain in use.
These alignment rules are not only implemented at the C language level,
but also at the LLVM IR level. This is done by selecting a different
DataLayout string depending on whether the vector ABI is in effect or not.
Based on a patch by Richard Sandiford.
llvm-svn: 236531
This is needed to prevent a TypoExpr from being corrected to a variable
when the TypoExpr is a subexpression of that variable's initializer.
Also exclude more keywords from the correction candidate pool when the
subsequent token is .* or ->* since keywords like "new" or "return"
aren't valid on the left side of those operators.
Fixes PR23140.
llvm-svn: 236519
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
llvm-svn: 236400
The MSVC ABI has a bug introduced by appending to the end of vftables
which come from virtual bases: covariant thunks introduces via
non-overlapping regions of the inheritance lattice both append to the
same slot in the vftable.
It is possible to generate correct vftables in cases where one node in
the lattice completely dominates the other on the way to the base with
the vfptr; in all other cases, we must raise a diagnostic in order to
prevent the illusion that we succeeded in laying out the vftable.
This fixes PR16759.
llvm-svn: 236354
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
llvm-svn: 236350
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.
This patch adds the necessary support to the clang frontend, and adds a
new test.
The compiler-rt and llvm parts are r236055 and r236288, respectively.
Patch by Teresa Johnson. Thanks!
llvm-svn: 236289
No functionality change; no-one inspects this field yet, and probably no-one
will ever inspect it in the "invalid" state, but ubsan could be unhappy about
this if such a DefInfo is copied.
llvm-svn: 236256
And thereby stop asserting.
In ObjC++ modes, we tentatively parse the lambda introducer twice: once
to disambiguate designators, which we also do in C++, and a second time
to disambiguate objc message expressions. During the second tentative
parse, the last cached token will be the annotation token we built in
the first parse. So use getLastLoc() to get the correct end location
for the rebuilt annotation.
llvm-svn: 236246
For proper codegen we need to capture variable in the OpenMP region. In loop-based directives loop control variables are private by default and they must be captured in this region. There was a problem with capturing of globals, used as lcv, as they was not marked as private by default.
Differential Revision: http://reviews.llvm.org/D9336
llvm-svn: 236201
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
This issue was fixed elsewhere in r235396 in a more general way, hence these
changes no longer do anything. Keep the testcase however, to ensure that we
don't regress this for ARM.
llvm-svn: 236104
In Objective-C some style guides use a style where assignment operators are
aligned, in an effort to increase code readability. This patch adds an option
to the format library which allows this functionality. It is disabled by
default for all the included styles, so it must be explicitly enabled.
The option will change code such as:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
to:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
Patch by Matt Oakes. Thank you!
Accidentally reformatted all the tests...
llvm-svn: 236100
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
llvm-svn: 236075
This is just the clang-side of 32-bit SEH. LLVM still needs work, and it
will determinstically fail to compile until it's feature complete.
On x86, all outlined handlers have no parameters, but they do implicitly
take the EBP value passed in and use it to address locals of the parent
frame. We model this with llvm.frameaddress(1).
This works (mostly), but __finally block inlining can break it. For now,
we apply the 'noinline' attribute. If we really want to inline __finally
blocks on 32-bit x86, we should teach the inliner how to untangle
frameescape and framerecover.
Promote the error diagnostic from codegen to sema. It now rejects SEH on
non-Windows platforms. LLVM doesn't implement SEH on non-x86 Windows
platforms, but there's nothing preventing it.
llvm-svn: 236052
some bugs in the ASTImporter that this exposed:
- When importing functions, the body (if any) was
previously ignored. This patch ensures that the
body is imported also.
- When a function-local Decl is imported, the first
thing the ASTImporter does is import its context
(via ImportDeclParts()). This can trigger
importing the Decl again as part of the body of
the function (but only once, since the function's
Decl has been added to ImportedDecls). This patch
fixes that problem by extending ImportDeclParts()
to return the imported Decl if it was imported as
part of importing its context, and the patch adds
ASTImporter::GetAlreadyImportedOrNull() to support
this query. All callers of ImportDeclParts return
the imported version of the Decl if ImportDeclParts()
returns it.
- When creating functions, InnerLocStart of the source
function was re-used without importing. This is a
straight up bug, and this patch makes ASTImporter
import the InnerLocStart and use the imported version.
- When importing FileIDs, the ASTImporter previously
always tried to re-load the file for the corresponding
CacheEntry from disk. This doesn't work if the
CacheEntry corresponds to a named memory buffer. This
patch changes the code so that if the UniqueID for the
cache entry is invalid (i.e., it is not a disk file)
the whole entry is treated as if it were invalid, which
forces an in-memory copy of the buffer.
Also added test cases, using the new support committed in
236011.
llvm-svn: 236012
When creating a global variable with a type of a struct with bitfields, we must
forcibly set the alignment of the global from the RecordDecl. We must do this so
that the proper bitfield alignment makes its way down to LLVM, since clang will
mangle the bitfields into one large type.
llvm-svn: 235976
the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.
llvm-svn: 235941
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
During device-side CUDA compilation clang currently complains about
all TLS variables, regardless of whether they are __host__ or
__device__.
This patch suppresses "TLS unsupported" errors for host variables
during device compilation and for device variables during host
compilation.
Differential Revision: http://reviews.llvm.org/D9269
llvm-svn: 235907
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
llvm-svn: 235903
Previously we'd defer this determination until writing the AST, which doesn't
allow us to use this information when building other submodules of the same
module. This change also allows us to use a uniform mechanism for writing
module macro records, independent of whether they are local or imported.
llvm-svn: 235614
This graph will be used to determine the current set of active macros. This is
foundation work for getting macro visibility correct across submodules of the
current module. No functionality change for now.
llvm-svn: 235461
- Changed CUDALaunchBounds arguments from integers to Expr* so they can
be saved in AST for instantiation.
- Added support for template instantiation of launch_bounds attrubute.
- Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo::
SetTargetAttributes() where it can be done after template instantiation.
- Added a warning on negative launch_bounds arguments.
- Amended test cases.
Differential Revision: http://reviews.llvm.org/D8985
llvm-svn: 235452
This is substantially simpler, provides better space usage accounting in bcanalyzer,
and gives a more compact representation. No functionality change intended.
llvm-svn: 235420
The GCC construct __attribute__((aligned)) is defined to set alignment
to "the default alignment for the target architecture" according to
the GCC documentation:
The default alignment is sufficient for all scalar types, but may not be
enough for all vector types on a target that supports vector operations.
The default alignment is fixed for a particular target ABI.
clang currently hard-coded an alignment of 16 bytes for that construct,
which is correct on some platforms (including X86), but wrong on others
(including SystemZ). Since this value is ABI-relevant, it is important
to get correct for compatibility purposes.
This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned"
that targets can set to the appropriate default __attribute__((aligned))
value.
Note that I'm deliberately *not* using the existing "SuitableAlign"
value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__,
since those two values may not be the same on all platforms. In fact,
on X86, __attribute__((aligned)) always uses 16-byte alignment, while
__BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported.
(This is actually not yet correctly implemented in clang either.)
The patch provides a value for DefaultAlignForAttributeAligned only for
SystemZ, and leaves the default for all other targets at 16, which means
no visible change in behavior on all other targets. (The value is still
wrong for some other targets, but I'd prefer to leave it to the target
maintainers for those platforms to fix.)
llvm-svn: 235397
in the context of the container itself.
Otherwise we will emit 'unavailable' errors when referencing an unavailable super class
even though the subclass is also marked 'unavailable'.
rdar://20598702
llvm-svn: 235276
__declspec(align(...)) is unlike all other attributes in that it is not
applied to a variable if it appears before the class-key. If the
tag in question isn't part of a variable declaration, it is not ignored.
Instead, the alignment attribute is applied to the tag.
This fixes PR18024.
llvm-svn: 235272
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
llvm-svn: 235166
This allows callers to pass a char ** (such as the one coming from the
standard decreed main declaration - even though everyone usually puts
const on that themselves).
llvm-svn: 235150
attribute to be placed on Objective-C pointer typedef
to make them strong enough so on their "new" method
family no attempt is made to override these
types. rdar://20255473
llvm-svn: 235128
Emits the following code for the clause at the beginning of the outlined function for implicit threads:
if (<not a master thread>) {
...
<thread local copy of var> = <master thread local copy of var>;
...
}
<sync point>;
Checking for a non-master thread is performed by comparing of the address of the thread local variable with the address of the master's variable. Master thread always uses original variables, so you always know the address of the variable in the master thread.
Differential Revision: http://reviews.llvm.org/D9026
llvm-svn: 235075
#pragma omp for lastprivate(<var>)
for (i = a; i < b; ++b)
<BODY>;
This construct is translated into something like:
<last_iter> = alloca i32
<lastprivate_var> = alloca <type>
<last_iter> = 0
; No initializer for simple variables or a default constructor is called for objects.
; For arrays perform element by element initialization by the call of the default constructor.
...
OMP_FOR_START(...,<last_iter>, ..); sets <last_iter> to 1 if this is the last iteration.
<BODY>
...
OMP_FOR_END
if (<last_iter> != 0) {
<var> = <lastprivate_var> ; Update original variable with the lastprivate value.
}
call __kmpc_cancel_barrier() ; an implicit barrier to avoid possible data race.
Differential Revision: http://reviews.llvm.org/D8658
llvm-svn: 235074
For CUDA source, Sema checks that the targets of call expressions make sense
(e.g. a host function can't call a device function).
Adding a flag that lets us skip this check. Motivation: for source-to-source
translation tools that have to accept code that's not strictly kosher CUDA but
is still accepted by nvcc. The source-to-source translation tool can then fix
the code and leave calls that are semantically valid for the actual compilation
stage.
Differential Revision: http://reviews.llvm.org/D9036
llvm-svn: 235049
"multiple methods named '<selector>' found" warning by noting
the method that is actualy used. It also cleans up and refactors
code in this area and selects a method that matches actual arguments
in case of receiver being a forward class object.
rdar://19265430
llvm-svn: 235023
Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.
This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).
llvm-svn: 234962
This patch generates a warning for invalid combination of '-mnan' and
'-march' options, it properly sets NaN encoding for a given '-march',
and it passes a proper NaN encoding to the assembler.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D8170
llvm-svn: 234882
-Wrange-loop-analysis is a subgroup of -Wloop-analysis and will warn when
a range-based for-loop makes copies of the elements in the range. If possible,
suggest the proper type to prevent copies, or the non-reference to help
distinguish copy versus non-copy forms. Existing warnings in -Wloop-analysis
are moved to -Wfor-loop-analysis, also a subgroup of -Wloop-analysis.
Differential Revision: http://reviews.llvm.org/D4169
llvm-svn: 234804
Peter Collingbourne