| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
svn 1.8.0 emits an additional line matching 'URL:' in its 'svn info' command
('Relative URL:').
Changed the grep to match only the intended line so that a valid SVNVersion.inc
is generated.
The problem doesnt occur with the svn version I'm using (1.7.5) but Tobias has
confirmed that the change fixes the problem.
See http://llvm.org/bugs/show_bug.cgi?id=17203
llvm-svn: 190685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
llvm-svn: 190684
|
| |
|
|
|
|
| |
Patch by Bradley Smith!
llvm-svn: 190683
|
| |
|
|
| |
llvm-svn: 190682
|
| |
|
|
|
|
|
|
| |
non-x-compile-safe tests
Patch by Artyom Skrobov!
llvm-svn: 190681
|
| |
|
|
| |
llvm-svn: 190680
|
| |
|
|
|
|
|
|
| |
non-x-compile-safe tests
Patch by Artyom Skrobov!
llvm-svn: 190679
|
| |
|
|
|
|
|
|
|
|
| |
Before (even with Style.Cpp11BracedListStyle):
f(MyMap[{ composite, key }]);
After:
f(MyMap[{composite, key}]);
llvm-svn: 190678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r187209, which modified ltdl.m4, I was unable to execute
AutoRegen.sh, getting:
../configure:10779: error: possibly undefined macro: AC_LTDL_FUNC_ARGZ
This commit re-adds AC_LTDL_FUNC_ARGZ to ltdl.m4, as a quick fix. For me, this
corresponds to the configure file currently checked in.
(However, the ltdl library seems to be unused since r74924 in 2009,
except for the use of the LTDL_SHLIB_EXT macro in
bugpoint(?). Therefore, the right solution seems to try to get rid of
the local ltdl.m4 file, specified by autoconf/README.TXT.)
llvm-svn: 190677
|
| |
|
|
| |
llvm-svn: 190676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655
Reviewers: timurrrr, pcc, rnk, whunt
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1670
llvm-svn: 190675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
enum {
Bar = Foo < int,
int > ::value
};
After:
enum {
Bar = Foo<int, int>::value
};
llvm-svn: 190674
|
| |
|
|
|
|
| |
Just a clean-up, no behavioral change intended.
llvm-svn: 190673
|
| |
|
|
|
|
| |
E.g. "SRL %r2, 2; TMLL %r2, 1" => "TMLL %r2, 4".
llvm-svn: 190672
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a first step to getting extern "C" working properly inside
clang. There are a number of quirks but mangling declarations inside
such a function are a good first step.
Reviewers: timurrrr, pcc, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1655
llvm-svn: 190671
|
| |
|
|
| |
llvm-svn: 190670
|
| |
|
|
| |
llvm-svn: 190669
|
| |
|
|
|
|
| |
disabled.
llvm-svn: 190668
|
| |
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=222
llvm-svn: 190667
|
| |
|
|
|
|
| |
performance)
llvm-svn: 190666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we modelled VPR128 and VPR64 as essentially identical
register-classes containing V0-V31 (which had Q0-Q31 as "sub_alias"
sub-registers). This model is starting to cause significant problems
for code generation, particularly writing EXTRACT/INSERT_SUBREG
patterns for converting between the two.
The change here switches to classifying VPR64 & VPR128 as
RegisterOperands, which are essentially aliases for RegisterClasses
with different parsing and printing behaviour. This fits almost
exactly with their real status (VPR128 == FPR128 printed strangely,
VPR64 == FPR64 printed strangely).
llvm-svn: 190665
|
| |
|
|
|
|
| |
rely on regular load and store and other signal-safe logic; b) remove allocated_from_size_class_mask_ which is not helping much anyway; Another 10% speedup
llvm-svn: 190664
|
| |
|
|
|
|
| |
async-signal safe.
llvm-svn: 190663
|
| |
|
|
| |
llvm-svn: 190662
|
| |
|
|
| |
llvm-svn: 190661
|
| |
|
|
| |
llvm-svn: 190660
|
| |
|
|
| |
llvm-svn: 190659
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This handles multiple weak symbols which appear back to back. This fix is needed
which otherwise will lead to symbols getting initialized to arbitrary values.
There was a constructor/destructor test that really triggered this to be fixed
on X86_64.
Adds a test.
llvm-svn: 190658
|
| |
|
|
|
|
|
| |
later in the code so that the expressions will have addition processing first.
This catches a few additional cases of uninitialized uses of class fields.
llvm-svn: 190657
|
| |
|
|
| |
llvm-svn: 190656
|
| |
|
|
|
|
|
| |
that duplicated the name of the entity being documented at the start of its
comment, and other minor tidyups.
llvm-svn: 190655
|
| |
|
|
|
|
|
|
| |
single-quote and double-quotemarks from around file paths specified to
settings like target.expr-prefix or target.process.python-os-plugin-path.
<rdar://problem/14970457>
llvm-svn: 190654
|
| |
|
|
| |
llvm-svn: 190653
|
| |
|
|
|
|
| |
Patch by Jared Grubb!
llvm-svn: 190652
|
| |
|
|
|
|
| |
Patch by Jared Grubb!
llvm-svn: 190651
|
| |
|
|
|
|
|
|
|
| |
No tests because no in-tree checkers use this, but that shouldn't stop
out-of-tree checkers.
Found by Aemon Cannon!
llvm-svn: 190650
|
| |
|
|
|
|
|
|
| |
versions of gold. This support is designed to allow gold to produce
gdb_index sections similar to the accelerator tables and consumable
by gdb.
llvm-svn: 190649
|
| |
|
|
| |
llvm-svn: 190648
|
| |
|
|
| |
llvm-svn: 190647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This restores the sqrt -> llvm.sqrt mapping, but only in fast-math mode
(specifically, when the UnsafeFPMath or NoNaNsFPMath CodeGen options are
enabled). The @llvm.sqrt* intrinsics have slightly different semantics from the
libm call, specifically, they are undefined when given a non-zero negative
number (the libm calls will always return NaN for any negative number).
This mapping was removed in r100613, and replaced with a TODO, but at that time
the fast-math flags were not yet implemented. Now that we have these, restoring
this mapping is important because it will enable autovectorization of sqrt
calls in loops (at least in fast-math mode).
llvm-svn: 190646
|
| |
|
|
| |
llvm-svn: 190645
|
| |
|
|
| |
llvm-svn: 190644
|
| |
|
|
|
|
|
| |
This move makes possible to correctly handle multiples instructions
from a single pattern.
llvm-svn: 190643
|
| |
|
|
|
|
|
|
| |
remember/restore state instructions.
This would prevent system calls on Linux from being able to backtrace correctly.
llvm-svn: 190642
|
| |
|
|
| |
llvm-svn: 190641
|
| |
|
|
| |
llvm-svn: 190640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.
The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).
This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.
There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.
Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.
llvm-svn: 190639
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>
llvm-svn: 190638
|
| |
|
|
| |
llvm-svn: 190637
|
| |
|
|
|
|
|
|
|
|
| |
When a structure is passed by value, and that structure contains a vector
member, according to the PPC ABI, the structure will receive enhanced alignment
(so that the vector within the structure will always be aligned).
This should resolve PR16641.
llvm-svn: 190636
|