| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
MacroDirective*, in order to preserve full information on module macro expansion.
llvm-svn: 236404
|
|
|
|
|
|
|
|
|
|
| |
Preprocessor::MacroDefinition -> MacroDefinition.
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
|
|
|
|
| |
llvm-svn: 236390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by tell().
Using GetNumBytesInBuffer() assumes that the stream was not flushed between
the GetNumBytesInBuffer() calls, which may happen to be true or not,
depending on stream policy. tell() always reports the correct stream location.
Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in
lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp.
The former may be replacable by tell (needs testing) but while the later can
not be immediatly replaced by tell() as it uses the absolute value of
GetNumBytesInBuffer() rather than the real stream position. Both uses seems
to depend upon flush policy and thus may not work correctly depending upon the
stream behaviour.
Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible
to raw_ostream clients.
llvm-svn: 236389
|
|
|
|
|
|
|
|
|
|
| |
OriginalColumn might not be set, so fall back to Location and SourceMgr
in case it is missing. Also initialize end column in case the token is
multi line, but it's the ` token itself that starts the multi line.
Patch by Martin Probst, thank you!
llvm-svn: 236383
|
|
|
|
|
|
|
|
|
|
| |
Parameters can have templated types and default values (= ...), which is
another location in which a template closer should be followed by
whitespace.
Patch by Martin Probst, thank you.
llvm-svn: 236382
|
|
|
|
|
|
|
|
| |
The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this
API to be accessible via CodeGenFunction rather than CodeGenPGO.
llvm-svn: 236380
|
|
|
|
| |
llvm-svn: 236376
|
|
|
|
|
|
| |
overrides nothing.
llvm-svn: 236374
|
|
|
|
|
|
|
|
|
|
| |
The underlying problem is that there is currently no way to run
ObjCARCContract from llvm bitcode which is required by ObjC ARC.
This fix the problem by always enable ObjCARCContract pass if
optimization is enabled. The ObjCARC Contract pass has almost no
overhead on code that is not using ARC.
llvm-svn: 236372
|
|
|
|
|
|
|
|
| |
unmatched l_paren before setting the LHS to ExprError().
Fixes PR23285.
llvm-svn: 236371
|
|
|
|
|
|
|
|
| |
No functional change. This just makes it more obvious that the logic
in ComputeRegionCounts only depends on the counter map and local
state.
llvm-svn: 236370
|
|
|
|
|
|
|
|
| |
should not export the macro.
... at least, not unless we have local submodule visibility enabled.
llvm-svn: 236369
|
|
|
|
|
|
|
|
|
| |
This removes the RegionCounter class, which is only used as a helper
in teh ComputeRegionCounts stmt visitor. This class is just an extra
layer of abstraction that makes the code harder to follow at this
point, and removing it makes the logic quite a bit more direct.
llvm-svn: 236364
|
|
|
|
| |
llvm-svn: 236355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
A class might contain multiple ways of getting to a vbase, some of which
are virtual and other non-virtual. It may be the case that a
non-virtual base contains an override of a method in a vbase. This
means that we must carefully pick between a set of nvbases to determine
which is the best.
As a consequence, the findPathForVPtr algorithm is considerably simpler.
llvm-svn: 236353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Cyclone actually supports all the goodies you'd expect to come with an AArch64
CPU, so it doesn't need its own clause. Also we should probably be testing
these clauses.
llvm-svn: 236349
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalid.
The LHS was already being corrected before being set to ExprError when
the RHS is invalid, but when it was present the middle of a ternary
expression would be dropped in the error paths.
Fixes PR23350.
llvm-svn: 236347
|
|
|
|
|
|
|
| |
This is needed to ensure the type casts are parsed properly. Fixes
PR23101.
llvm-svn: 236337
|
|
|
|
| |
llvm-svn: 236335
|
|
|
|
|
|
| |
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 236325
|
|
|
|
| |
llvm-svn: 236315
|
|
|
|
| |
llvm-svn: 236301
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 236298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 236285
|
|
|
|
| |
llvm-svn: 236281
|
|
|
|
|
|
| |
Wire this up to "#pragma clang __debug macro <name>".
llvm-svn: 236280
|
|
|
|
|
|
|
|
|
| |
We were assigning the counter for the body of the loop to the loop
variable initialization for some reason here, but our tests completely
lacked coverage for range-for loops. This fixes that and makes the
logic generally more similar to the logic for a regular for.
llvm-svn: 236277
|
|
|
|
|
|
| |
lib/Basic/Targets.cpp
llvm-svn: 236274
|
|
|
|
| |
llvm-svn: 236271
|
|
|
|
| |
llvm-svn: 236264
|
|
|
|
| |
llvm-svn: 236243
|
|
|
|
|
|
|
|
|
|
| |
unavailable.
This probably won't come up much, but it seems tidier.
Related to rdar://problem/20713550
llvm-svn: 236242
|
|
|
|
|
|
|
|
|
|
| |
is parsed.
That way we can take any trailing availability attributes into account.
rdar://problem/20713550
llvm-svn: 236241
|
|
|
|
|
|
|
|
|
|
|
|
| |
There can be multiple virtual bases which are on the path to a vfptr
when one vbase virtually inherits from another. We should prefer the
most derived virtual base which covariantly overrides a method in the
vfptr class; if we do not lengthen the path this way, we will end up
with too few vftable entries.
This fixes PR21073.
llvm-svn: 236239
|
|
|
|
|
|
| |
by Asaf Badouh (asaf.badouh@intel.com)
llvm-svn: 236218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before (with the appropriate flags settings):
if (a) {
f();
} else { g(); }
Before (with other appropriate flags settings):
if (a) { f(); } else {
g();
}
After:
if (a) {
f();
} else {
g();
}
llvm-svn: 236217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For tasks codegen for private/firstprivate variables are different rather than for other directives.
1. Build an internal structure of privates for each private variable:
struct .kmp_privates_t. {
Ty1 var1;
...
Tyn varn;
};
2. Add a new field to kmp_task_t type with list of privates.
struct kmp_task_t {
void * shareds;
kmp_routine_entry_t routine;
kmp_int32 part_id;
kmp_routine_entry_t destructors;
.kmp_privates_t. privates;
};
3. Create a function with destructors calls for all privates after end of task region.
kmp_int32 .omp_task_destructor.(kmp_int32 gtid, kmp_task_t *tt) {
~Destructor(&tt->privates.var1);
...
~Destructor(&tt->privates.varn);
return 0;
}
4. Perform default initialization of all private fields (no initialization for POD data, default constructor calls for classes) + provide address of a destructor function after kmpc_omp_task_alloc() and before kmpc_omp_task() calls.
kmp_task_t *new_task = __kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid, kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds, kmp_routine_entry_t *task_entry);
DefaultConstructor(new_task->privates.var1);
new_task->shareds.var1_ref = &new_task->privates.var1;
...
DefaultConstructor(new_task->privates.varn);
new_task->shareds.varn_ref = &new_task->privates.varn;
new_task->destructors = .omp_task_destructor.;
kmp_int32 __kmpc_omp_task(ident_t *, kmp_int32 gtid, kmp_task_t *new_task)
Differential Revision: http://reviews.llvm.org/D9322
llvm-svn: 236207
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixed initialization of 'single' region completion + changed type of the third argument of __kmpc_copyprivate() runtime function to size_t.
llvm-svn: 236198
|
|
|
|
| |
llvm-svn: 236197
|
|
|
|
|
|
|
|
|
| |
a FileID corresponds to a real file or to a
memory buffer. The old method didn't work when
Clang was built Release, which meant it wasn't
a very good method at all.
llvm-svn: 236188
|
|
|
|
| |
llvm-svn: 236181
|
|
|
|
|
|
|
|
|
| |
by erasing the soft-float target feature if the rest of the front
end added it because of defaults or the soft float option.
Add some testing for some of the targets that implement this hack.
llvm-svn: 236179
|
|
|
|
| |
llvm-svn: 236178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|