| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions when safe (PR24593)
This patch does two things:
1) Don't error about dllimport/export on thread-local static local variables.
We put those attributes on static locals in dllimport/export functions
implicitly in case the function gets inlined. Now, for TLS variables this
is a problem because we can't import such variables, but it's a benign
problem becase:
2) Make sure we never inline a dllimport function TLS static locals. In fact,
never inline a dllimport function that references a non-imported function
or variable (because these are not defined in the importing library). This
seems to match MSVC's behaviour.
Differential Revision: http://reviews.llvm.org/D12422
llvm-svn: 246338
|
| |
|
|
| |
llvm-svn: 246324
|
| |
|
|
|
|
| |
This reverts commit r246223, as it broke all ARM/AArch64 bots.
llvm-svn: 246323
|
| |
|
|
| |
llvm-svn: 246322
|
| |
|
|
|
|
| |
This reverts commit r246211, as it broke all ARM/AArch64 bots.
llvm-svn: 246321
|
| |
|
|
|
|
| |
This reverts commit r246206, as it broke all ARM/AArch64 bots.
llvm-svn: 246320
|
| |
|
|
|
|
| |
This reverts commit r246204, as it was breaking all ARM/AArch64 bots.
llvm-svn: 246319
|
| |
|
|
| |
llvm-svn: 246303
|
| |
|
|
|
|
|
|
|
|
| |
Summary: Patch by Steven Chamberlain <steven@pyro.eu.org>
Reviewers: uweigand
Differential Revision: http://reviews.llvm.org/D12430
llvm-svn: 246295
|
| |
|
|
|
|
|
| |
The test is currently failing on bots:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12747/
llvm-svn: 246288
|
| |
|
|
|
|
| |
These two commits causes llvm LTO bootstrap to hang in ScalarEvolution.
llvm-svn: 246282
|
| |
|
|
|
|
| |
Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type).
llvm-svn: 246278
|
| |
|
|
|
|
| |
pointer to an RVO construction of a returned object.
llvm-svn: 246263
|
| |
|
|
| |
llvm-svn: 246260
|
| |
|
|
|
|
| |
and replace all callers.
llvm-svn: 246259
|
| |
|
|
|
|
|
|
| |
Sometimes, a macro that expands to another macro name will not be printed in
the macro backtrace. This patch finds the missed macro expansions and prints
them. Fixes PR16799
llvm-svn: 246237
|
| |
|
|
|
|
| |
them more than once. (NFC)
llvm-svn: 246231
|
| |
|
|
|
|
|
|
|
|
|
| |
Without this, 64-byte vector types (__m512), specified to be 64-byte
aligned in the AVX512 draft SysV ABI, will only be 32-byte aligned.
This is analoguous to AVX, for which we accept 32-byte max alignment.
Differential Revision: http://reviews.llvm.org/D10724
llvm-svn: 246230
|
| |
|
|
|
|
|
|
|
| |
There's no point in using a larger alignment if we have no instructions
that would benefit from it.
Differential Revision: http://reviews.llvm.org/D12389
llvm-svn: 246229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ABI string only exists to communicate with TargetCodeGenInfo.
Concretely, since we only used "avx*" ABI strings on x86_64 (as AVX
doesn't affect the i386 ABIs), this meant that, when initializing
SimdDefaultAlign, we would ignore AVX/AVX512 on i386, for no good
reason.
Instead, directly check the features. A similar change for
MaxVectorAlign will follow.
Differential Revision: http://reviews.llvm.org/D12390
llvm-svn: 246228
|
| |
|
|
| |
llvm-svn: 246225
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246223
|
| |
|
|
| |
llvm-svn: 246215
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There was linker problem, and it turns out that it is not always safe
to refer to vtable. If the vtable is used, then we can refer to it
without any problem, but because we don't know when it will be used or
not, we can only check if vtable is external or it is safe to to emit it
speculativly (when class it doesn't have any inline virtual functions).
It should be fixed in the future.
http://reviews.llvm.org/D12385
llvm-svn: 246214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
http://reviews.llvm.org/D11859
llvm-svn: 246213
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246211
|
| |
|
|
|
|
|
|
|
|
|
| |
Usually debug info is created on the fly while during codegen.
With this API it becomes possible to create standalone debug info
for types that are not referenced by any code, such as emitting debug info
for a clang module or for implementing something like -gfull.
Because on-the-fly debug info generation may still insert retained types
on top of them, all RetainedTypes are uniqued in CGDebugInfo::finalize().
llvm-svn: 246210
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246206
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246204
|
| |
|
|
| |
llvm-svn: 246202
|
| |
|
|
|
|
| |
Minor tweak to rL246083
llvm-svn: 246200
|
| |
|
|
| |
llvm-svn: 246197
|
| |
|
|
| |
llvm-svn: 246196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of changes here:
a) Do less work in the case where we don't have a target attribute on the
function. We've already canonicalized the attributes for the function -
no need to do more work.
b) Use the newer canonicalized feature adding functions from TargetInfo
to do the work when we do have a target attribute. This enables us to diagnose
some warnings in the case of conflicting written attributes (only ppc does
this today) and also make sure to get all of the features for a cpu that's
listed rather than just change the cpu.
Updated all testcases accordingly and added a new testcase to verify that we'll
error out on ppc if we have some incompatible options using the existing diagnosis
framework there.
llvm-svn: 246195
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11950
llvm-svn: 246193
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
llvm-svn: 246192
|
| |
|
|
|
|
|
|
|
|
|
| |
The LLVM patch changes the analysis diagnostics produced when loops with
floating-point recurrences or memory operations are identified. The new messages
say "cannot prove it is safe to reorder * operations; allow reordering by
specifying #pragma clang loop vectorize(enable)". Depending on the type of
diagnostic the message will include additional options such as ffast-math or
__restrict__.
llvm-svn: 246189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
!RemainingNodes.empty() && "No error node found in the trimmed graph"
The assertion is caused by reusing a “filler” ExplodedNode as an error node.
The “filler” nodes are only used for intermediate processing and are not
essential for analyzer history, so they can be reclaimed when the
ExplodedGraph is trimmed by the “collectNode” function. When a checker finds a
bug, they generate a new transition in the ExplodedGraph. The analyzer will
try to reuse the existing predecessor node. If it cannot, it creates a new
ExplodedNode, which always has a tag to uniquely identify the creation site.
The assertion is caused when the analyzer reuses a “filler” node.
In the test case, some “filler” nodes were reused and then reclaimed later
when the ExplodedGraph was trimmed. This caused an assertion because the node
was needed to generate the report. The “filler” nodes should not be reused as
error nodes. The patch adds a constraint to prevent this happening, which
solves the problem and makes the test cases pass.
Differential Revision: http://reviews.llvm.org/D11433
Patch by Ying Yi!
llvm-svn: 246188
|
| |
|
|
|
|
|
| |
This 2nd patch should not change the test results, but it is useful if clang's
default C++ language is ever changed from gnu++98.
llvm-svn: 246183
|
| |
|
|
|
|
|
|
| |
events.
Differential Revision: http://reviews.llvm.org/D11433
llvm-svn: 246182
|
| |
|
|
| |
llvm-svn: 246180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation tries to guess which Action will result in a
job which needs to incorporate device-side GPU binaries. The guessing
was attempting to work around the fact that multiple actions may be
combined into a single compiler invocation. If CudaHostAction ends up
being combined (and thus bypassed during action list traversal) no
device-side actions it pointed to were processed. The guessing worked
for most of the usual cases, but fell apart when external assembler
was used.
This change removes the guessing and makes sure we create and pass
device-side jobs regardless of how the jobs get combined.
* CudaHostAction is always inserted either at Compile phase or the
FinalPhase of current compilation, whichever happens first.
* If selectToolForJob combines CudaHostAction with other actions, it
passes info about CudaHostAction up to the caller
* When it sees that CudaHostAction got combined with other actions
(and hence will never be passed to BuildJobsForActions),
BuildJobsForActions creates device-side jobs the same way they would
be created if CudaHostAction was passed to BuildJobsForActions
directly.
* Added two more test cases to make sure GPU binaries are passed to
correct jobs.
Differential Revision: http://reviews.llvm.org/D11280
llvm-svn: 246174
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Constructor() : initializer(0) {}
template <typename T>
Constructor()
: initializer(0) {}
After:
Constructor() : initializer(0) {}
template <typename T>
Constructor() : initializer(0) {}
llvm-svn: 246146
|
| |
|
|
|
|
|
|
|
| |
with multiple uses of feature map construction.
Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.
llvm-svn: 246128
|
| |
|
|
| |
llvm-svn: 246127
|
| |
|
|
|
|
|
|
| |
DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in the type used as the lookup table key. As a side-effect, remove
one copy of the duplicated code used to compute the hash of the key.
llvm-svn: 246124
|
| |
|
|
|
|
| |
this is going to see use shortly in unifying feature set construction.
llvm-svn: 246122
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11468
llvm-svn: 246105
|
| |
|
|
| |
llvm-svn: 246099
|
| |
|
|
|
|
|
|
| |
I stared at `false /*declaration*/` for quite some time before giving up
and checking the actual function to see what it meant. Replacing with
`/* isDefinition = */ false` to save myself effort later.
llvm-svn: 246095
|