| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Namely, we must have proper C++ABI support in UBSan runtime. We don't
have a good way to check for that, so just assume that C++ABI support is
there whenever -fsanitize=vptr is supported (i.e. only on handful of
platforms).
Exact diagnostic is also tricky. It's not "cfi" that is unsupported,
just the diagnostic mode. So, I suggest to report that
"-fno-sanitize-trap=cfi-foobar" is incompatible with a given target
toolchain.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10751
llvm-svn: 240716
|
| |
|
|
|
|
|
|
|
| |
When a profile file cannot be opened, we used to display just the error
message but not the name of the profile the compiler was trying to open.
This will become useful in the next set of patches that introduce
GCC-compatible flags to specify profiles.
llvm-svn: 240715
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the functionality specified by DR948.
The changes are two fold. First, the parser was modified
to allow 'constexpr's to appear in condition declarations
(which was a hard error before). Second, Sema was modified
to cleanup maybe odr-used declarations by way of a call to
'ActOnFinishFullExpr'. As 'constexpr's were not allowed in
condition declarations before the cleanup wasn't necessary
(such declarations were always odr-used).
This fixes PR22491.
Differential Revision: http://reviews.llvm.org/D8978
llvm-svn: 240707
|
| |
|
|
|
|
| |
parsing then merged again when the module was loaded.
llvm-svn: 240700
|
| |
|
|
|
|
|
| |
To match the '-ccc-print-phases' command-line flag.
Also make two more 'for' loops range-based. NFC
llvm-svn: 240680
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10738
llvm-svn: 240674
|
| |
|
|
|
|
|
|
|
|
|
| |
Integer variants are implemented as atomicrmw or cmpxchg instructions.
Atomic add for floating point (__nvvm_atom_add_gen_f()) is implemented
as a call to an overloaded @llvm.nvvm.atomic.load.add.f32.* LVVM
intrinsic.
Differential Revision: http://reviews.llvm.org/D10666
llvm-svn: 240669
|
| |
|
|
| |
llvm-svn: 240664
|
| |
|
|
|
|
|
|
| |
name. The local should not be renamed, only the externally-available declaration should be.
Patch by Andrey Bokhanko!
llvm-svn: 240653
|
| |
|
|
|
|
|
|
| |
Patch by takeshi-yoshimura!
Differential Revision: http://reviews.llvm.org/D10145
llvm-svn: 240643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the Clang part of the PPC64 memory sanitizer implementation in
D10648.
Reviewers: kcc, eugenis, willschm, wschmidt, samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10650
llvm-svn: 240628
|
| |
|
|
|
|
|
|
|
|
| |
Before:
optional string operator= 1;
After:
optional string operator = 1;
llvm-svn: 240624
|
| |
|
|
|
|
|
|
|
|
| |
This re-commits r226005 with a tweak. The origin attempt failed because
Darwin bot sets up SDKROOT and clang can deduce SDK version from them
after this patch. That broke many driver tests due to the change of
deployment target version. Now the tests should not complain after
r240574.
llvm-svn: 240619
|
| |
|
|
|
|
|
| |
See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this
is necessary.
llvm-svn: 240618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch reduces duplication in the template argument deduction code
for handling deduction from initializer lists in a function call. This
extends the fix for PR12119 to also apply to the case where the
corresponding parameter is a trailing parameter pack.
Test Plan:
A test for deduction from nested initializer lists where the
corresponding parameter is a trailing parameter pack is added in
`clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp`.
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10681
llvm-svn: 240612
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change implements parse-only acceptance of the optional
requires-clause in a template-declaration. Diagnostic testing is added
for cases where the grammar is ambiguous with the expectation that the
longest token sequence which matches the syntax of a
constraint-expression is consumed without backtracking.
Reviewers: faisalv, fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10462
llvm-svn: 240611
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when iterating through the Features vector if we don't
keep track of what's already been set. This could lead to
the macro __ARM_FP getting the wrong value. This patch
fixes this issue by keeping track of the bits that have
already been set in the loop.
Differential Revision: http://reviews.llvm.org/D10395
llvm-svn: 240607
|
| |
|
|
| |
llvm-svn: 240601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Byval argument pair formation assumes that if a type is less than 8 bytes
it must be an integer and not a pointer, which is not true for x32 and NaCl.
Relax the assertion and add a test for a codegen case that triggered it.
Reviewers: jvoung
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D10701
llvm-svn: 240600
|
| |
|
|
|
|
| |
Addresses the rest of rdar://problem/21530726.
llvm-svn: 240597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_Uppercase_underscored
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
llvm-svn: 240596
|
| |
|
|
|
|
|
|
|
|
|
|
| |
So, iterate over the list of macros mentioned in modules, and make sure those
are in the master table.
This isn't particularly efficient, but hopefully it's something that isn't
done too often.
PR23929 and rdar://problem/21480635
llvm-svn: 240571
|
| |
|
|
| |
llvm-svn: 240548
|
| |
|
|
| |
llvm-svn: 240545
|
| |
|
|
|
|
|
|
| |
If task directive has associated 'depend' clause then function kmp_int32 __kmpc_omp_task_with_deps ( ident_t *loc_ref, kmp_int32 gtid, kmp_task_t * new_task, kmp_int32 ndeps, kmp_depend_info_t *dep_list,kmp_int32 ndeps_noalias, kmp_depend_info_t *noalias_dep_list) must be called instead of __kmpc_omp_task().
If this directive has associated 'if' clause then also before a call of kmpc_omp_task_begin_if0() a function void __kmpc_omp_wait_deps ( ident_t *loc_ref, kmp_int32 gtid, kmp_int32 ndeps, kmp_depend_info_t *dep_list, kmp_int32 ndeps_noalias, kmp_depend_info_t *noalias_dep_list) must be called.
Array sections are not supported yet.
llvm-svn: 240532
|
| |
|
|
|
|
| |
for StringRef now that the core DenseMap library provides this facility.
llvm-svn: 240530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a serious bug in r240462: checking the BuiltinID for
ARM::BI_MoveToCoprocessor* in EmitBuiltinExpr() ignores the fact that
each target has an overlapping range of the BuiltinID values. That check
can trigger for builtins from other targets, leading to very bad
behavior.
Part of the reason I did not implement r240462 this way to begin with is
the special handling of the last argument for Neon builtins. In this
change, I have factored out the check to see which builtins have that
extra argument into a new HasExtraNeonArgument() function. There is still
some awkwardness in having to check for those builtins in two separate
places, i.e., once to see if the extra argument is present and once to
generate the appropriate IR, but this seems much cleaner than my previous
patch.
llvm-svn: 240522
|
| |
|
|
|
|
| |
Added special RAII class for proper values changing/restoring in CodeGenFunction::CapturedStmtInfo.
llvm-svn: 240517
|
| |
|
|
| |
llvm-svn: 240476
|
| |
|
|
|
|
| |
This is consistent with all other classes in Tools.h.
llvm-svn: 240464
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Microsoft-extension _MoveToCoprocessor and _MoveToCoprocessor2
builtins take the register value to be moved as the first argument,
but the corresponding mcr and mcr2 LLVM intrinsics expect that value
to be the third argument. Handle this as a special case, while still
leaving those intrinsics as generic MSBuiltins. I considered the
alternative of handling these in EmitARMBuiltinExpr, but that does
not work well for the follow-up change that I'm going to make to improve
the error handling for PR22560 -- we need the GetBuiltinType() checks
for ICEArguments, and the ARM version of that code is only used for
Neon intrinsics where the last argument is special and not
checked in the normal way.
llvm-svn: 240462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Classes in Tools.h inherit ultimately from Tool, which is a noun,
but subclasses of Tool were named for their operation, such as "Compile",
wherein the constructor call "Compile(args...)" could be misconstrued
as actually causing a compile to happen.
Likewise various other methods were not harmonious with their effect,
in that "BuildLinker()" returned a "new namespace::Link(...)"
instead of a "new namespace::Linker(...)" which it now does.
Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names.
And there is no particulary great way to name the "Lipo-er" and a few others.
Differential Revision: http://reviews.llvm.org/D10595
llvm-svn: 240455
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Virtual inheritance member pointers are always relative to the vbindex,
even when the member pointer doesn't point into a virtual base. This is
corrected by adjusting the non-virtual offset backwards from the vbptr
back to the top of the most derived class. While we performed this
adjustment when manifesting member pointers as constants or when
performing conversions, we didn't perform the adjustment when mangling
them.
llvm-svn: 240453
|
| |
|
|
| |
llvm-svn: 240452
|
| |
|
|
|
|
|
|
|
|
| |
Regular function calls (such as to cabs()) run into the same problem
with handling dependent exprs, not just builtins with custom type
checking.
Fixes PR23775.
llvm-svn: 240443
|
| |
|
|
|
|
|
|
|
| |
checking those calls when not in C++ mode, since those code paths can't
handle dependent exprs.
Fixes PR23740.
llvm-svn: 240441
|
| |
|
|
| |
llvm-svn: 240434
|
| |
|
|
|
|
|
| |
Any extra features from -fmodule-feature are part of the module hash and
need to get validated on load. Also print them with -module-file-info.
llvm-svn: 240433
|
| |
|
|
| |
llvm-svn: 240432
|
| |
|
|
|
|
| |
Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0).
llvm-svn: 240409
|
| |
|
|
| |
llvm-svn: 240406
|
| |
|
|
|
|
| |
to the caller instead of hiding it in emitReport. NFC.
llvm-svn: 240400
|
| |
|
|
|
| |
FIXME: Should "Level" be unsigned?
llvm-svn: 240391
|
| |
|
|
|
|
|
|
| |
VXABI' :
not all control paths return a value.
llvm-svn: 240389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Member pointers in the MS ABI are made complicated due to the following:
- Virtual methods in the most derived class (MDC) might live in a
vftable in a virtual base.
- There are four different representations of member pointer: single
inheritance, multiple inheritance, virtual inheritance and the "most
general" representation.
- Bases might have a *more* general representation than classes which
derived from them, a most surprising result.
We believed that we could treat all member pointers as-if they were a
degenerate case of the multiple inheritance model. This fell apart once
we realized that implementing standard member pointers using this ABI
requires referencing members with a non-zero vbindex.
On a bright note, all but the virtual inheritance model operate rather
similarly. The virtual inheritance member pointer representation
awkwardly requires a virtual base adjustment in order to refer to
entities in the MDC.
However, the first virtual base might be quite far from the start of the
virtual base. This means that we must add a negative non-virtual
displacement.
However, things get even more complicated. The most general
representation interprets vbindex zero differently from the virtual
inheritance model: it doesn't reference the vbtable at all.
It turns out that this complexity can increase for quite some time:
consider a derived to base conversion from the most general model to the
multiple inheritance model...
To manage this complexity we introduce a concept of "normalized" member
pointer which allows us to treat all three models as the most general
model. Then we try to figure out how to map this generalized member
pointer onto the destination member pointer model. I've done my best to
furnish the code with comments explaining why each adjustment is
performed.
This fixes PR23878.
llvm-svn: 240384
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI has very complicated member pointers. Don't attempt to
synthesize the final member pointer ab ovo usque ad mala in one go.
Instead, start with a member pointer which points to the declaration in
question as-if it's decl context was the target class. Then, utilize
our conversion logical to convert it to the target type.
This allows us to simplify how we think about member pointers because we
don't need to consider non-zero nv adjustments before we even generate
the member pointer. Furthermore, it gives our adjustment logic more
exposure by utilizing it in a common path.
llvm-svn: 240383
|
| |
|
|
| |
llvm-svn: 240382
|
| |
|
|
|
|
|
| |
Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy.
Differential Revision: http://reviews.llvm.org/D9550
llvm-svn: 240377
|
| |
|
|
|
|
| |
(Caused by r240370)
llvm-svn: 240376
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10612
llvm-svn: 240370
|