| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
module, use the path from the module map file in preference to the path from
the .pcm file when resolving relative paths in the .pcm file. This allows
diagnostics (and .d output) to give relative paths if the module was found via
a relative path.
llvm-svn: 223577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
This is a recommit of r223443, reverted in r223465; when joining together
imported file paths, we now use the system's separator rather than always
using '/'. This avoids path mismatches between the original module build and
the module user on Windows (at least, in some cases). A more comprehensive
fix will follow.
llvm-svn: 223539
|
|
|
|
| |
llvm-svn: 223465
|
|
|
|
|
|
|
|
|
| |
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
llvm-svn: 223443
|
|
|
|
| |
llvm-svn: 223105
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
|
|
|
|
|
|
|
|
| |
to be newer than we were expecting. That happens if .pcm's get moved between
file systems during a distributed build. (It's still not OK for them to actually
be different, though, so we still check the size and signature matches.)
llvm-svn: 222507
|
|
|
|
|
|
|
|
|
| |
special member function.
No test yet: the only testcases we have for this issue are extremely complex.
Testcase will be added once I get a reasonable reduction.
llvm-svn: 222506
|
|
|
|
|
|
| |
pair<iterator, bool> as per the C++ standard's associative container concept.
llvm-svn: 222335
|
|
|
|
|
|
| |
According to OpenMP standard, Section 2.12.6, atomic Construct, '#pragma omp atomic read' is allowed to be used only for expression statements of form 'v = x;', where x and v (as applicable) are both l-value expressions with scalar type. Patch adds checks for it.
llvm-svn: 222231
|
|
|
|
|
|
| |
module file.
llvm-svn: 222224
|
|
|
|
|
|
|
| |
is a re-commit of Doug's r154844 (modernized and updated to fit into current
Clang).
llvm-svn: 221918
|
|
|
|
| |
llvm-svn: 221786
|
|
|
|
| |
llvm-svn: 221784
|
|
|
|
|
|
|
|
|
| |
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
llvm-svn: 221663
|
|
|
|
|
|
|
|
| |
is enabled. Unlike system headers, we want to be more careful about
modifications to user headers, because it's still easy to edit a header
while you're building.
llvm-svn: 221634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
|
|
|
|
|
|
|
|
|
|
| |
We may need to verify the signature on subsequent imports as well, just
like we verify the size/modtime:
@import A;
@import B; // imports A
@import C; // imports A
llvm-svn: 221569
|
|
|
|
| |
llvm-svn: 221567
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
|
|
|
|
| |
llvm-svn: 220955
|
|
|
|
|
|
| |
unit, allow the -O settings of the two compilations to differ.
llvm-svn: 220943
|
|
|
|
|
|
|
|
| |
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
llvm-svn: 220850
|
|
|
|
| |
llvm-svn: 220812
|
|
|
|
|
|
|
|
| |
explicitly using the resulting .pcm file. Unlike for an implicit module build,
we don't need nor want to require these flags to match between the module
and its users.
llvm-svn: 220780
|
|
|
|
| |
llvm-svn: 220738
|
|
|
|
| |
llvm-svn: 220731
|
|
|
|
| |
llvm-svn: 220692
|
|
|
|
|
|
|
| |
This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.
llvm-svn: 220657
|
|
|
|
| |
llvm-svn: 220589
|
|
|
|
|
|
| |
The control flow and ownership is weird enough so unique_ptr doesn't help here :(
llvm-svn: 220569
|
|
|
|
|
|
| |
against changes to record order.
llvm-svn: 220524
|
|
|
|
|
|
| |
change.
llvm-svn: 220521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
llvm-svn: 220493
|
|
|
|
|
|
|
|
| |
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
|
|
|
|
|
|
| |
their only use was with the AST reader, and friendship can be used to handle that. Drive-by rename of "Brac" to "Brace" for the private data members. NFC.
llvm-svn: 220428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
|
|
|
|
|
|
| |
into multiple merged classes' TypeForDecl slots.
llvm-svn: 220331
|
|
|
|
|
|
|
| |
This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D4752
llvm-svn: 220262
|
|
|
|
|
|
|
|
| |
Now that we no longer add mappings when there are no local entities,
there is no need to always bump the size of the tables that correspond
to ContinuousRangeMaps.
llvm-svn: 220208
|
|
|
|
|
|
|
|
|
|
|
| |
This is a better fix for 'duplicate key' problems in module continuous
range maps (vs what I added in r215810) by not adding any mappings at
all when there are no local entities. Now it also covers selectors,
which were not always being bumped because the record SELECTOR_OFFSET is
not always emitted. I'll back out most of r215810 in a future commit,
since it should no longer be needed.
llvm-svn: 220207
|
|
|
|
|
|
| |
Code review feedback from Richard Smith on r219900.
llvm-svn: 220060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference-ness, etc) for non-type template parameters
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
|
|
|
|
| |
llvm-svn: 219657
|
|
|
|
| |
llvm-svn: 219561
|
|
|
|
|
|
| |
until after we've had a chance to merge that tag.
llvm-svn: 219539
|
|
|
|
|
|
|
|
| |
initializers, and captured VLA types so that we can
answer questions like "is this a bit-field" without
looking at the enclosing DeclContext. NFC.
llvm-svn: 219522
|
|
|
|
|
|
|
|
| |
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365
llvm-svn: 219393
|
|
|
|
|
|
| |
Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.
llvm-svn: 219385
|
|
|
|
|
|
|
|
| |
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140
llvm-svn: 219306
|