| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
The getARMTargetCPU and getLLVMArchSuffixForARM functions exist in both
Toolchain.cpp and Tools.cpp. This stuff needs a thorough overhaul. In the
meantime, this patch at least makes them consistent. One version had been
converted to use StringSwitch, and the other version had new Cortex M-series
processors added.
llvm-svn: 153202
|
| |
|
|
|
|
|
| |
c-mode to match behavior with void functions in c. Issue
warning with -pedantic. // rdar://11069896
llvm-svn: 153200
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On Darwin the architecture and the corresponding Mach-O slice is typically
specified with -arch. If not, it defaults to the current host architecture.
Do not use -mcpu to override the -arch value. This is only an issue when
people need to use specialized code for a non-default CPU (hopefully guarded
by run-time checks to detect the current processor). The -mcpu option is
still used for the -target-cpu option to clang, but this patch causes it to
not be used to set the architecture in the target triple.
llvm-svn: 153197
|
| |
|
|
|
|
|
| |
pointer field declarations in several meta-data.
// rdar://11079898
llvm-svn: 153196
|
| |
|
|
| |
llvm-svn: 153195
|
| |
|
|
| |
llvm-svn: 153193
|
| |
|
|
|
|
|
| |
pointer field declarations in several meta-data.
// rdar://11079898
llvm-svn: 153192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in vtable layout where virtual methods inherited from virtual bases
could be assigned the same vcall adjustment slot if they shared
a name and parameter signature but differed in their
cv-qualification. The code was already trying to handle this
case, but unfortunately used the ordinary type qualifiers
(which are always empty here) instead of the method qualifiers.
This seems like something that the API should discourage, but
I don't know how to carry that principle out in this instance.
Eliminate this function's need for an ASTContext while we're at it.
This bug affects the ABI, and fixing it brings us into accord with
the Itanium ABI (and GCC's implementation of it), but, obviously,
technically breaks full compatibility with previous releases of Clang.
Just letting you know.
llvm-svn: 153168
|
| |
|
|
| |
llvm-svn: 153167
|
| |
|
|
|
|
| |
(StringRef)getName() can be used here.
llvm-svn: 153156
|
| |
|
|
|
|
|
|
| |
of references to function template parameters in noexcept clauses when
the instantiation is forced from a point during parsing when a block
is in scope.
llvm-svn: 153152
|
| |
|
|
|
|
| |
// rdar://11076938
llvm-svn: 153151
|
| |
|
|
| |
llvm-svn: 153149
|
| |
|
|
| |
llvm-svn: 153146
|
| |
|
|
|
|
| |
// rdar://11079898
llvm-svn: 153145
|
| |
|
|
| |
llvm-svn: 153142
|
| |
|
|
|
|
| |
the external link.
llvm-svn: 153141
|
| |
|
|
|
|
|
| |
the class pointer in the category structure.
// rdar://11076938
llvm-svn: 153138
|
| |
|
|
| |
llvm-svn: 153130
|
| |
|
|
| |
llvm-svn: 153129
|
| |
|
|
| |
llvm-svn: 153127
|
| |
|
|
| |
llvm-svn: 153126
|
| |
|
|
| |
llvm-svn: 153124
|
| |
|
|
| |
llvm-svn: 153123
|
| |
|
|
|
|
| |
<rdar://problem/11040133>.
llvm-svn: 153122
|
| |
|
|
|
|
|
|
| |
invalidating the pointer.
Fixes PR12284. The test case only triggered under asan/valgrind, but it's better than nothing.
llvm-svn: 153120
|
| |
|
|
|
|
|
| |
via functions for certain pointer initialization
fields. // rdar://11076938
llvm-svn: 153117
|
| |
|
|
|
|
|
|
| |
replaceOperandWith.
TrackingVH notices when it gets RAUW'd. Fixes PR12305 and PR12315.
llvm-svn: 153115
|
| |
|
|
|
|
|
| |
changes to how meta-data is declared.
// rdar://11076938
llvm-svn: 153098
|
| |
|
|
| |
llvm-svn: 153096
|
| |
|
|
|
|
|
| |
one place and use it throughout. Also, change ivar name to avoid
name collisions. // rdar://11079366
llvm-svn: 153093
|
| |
|
|
|
|
|
|
|
| |
From the Intel Optimization Reference Manual, Section 11.6.2. When data cannot
be aligned or alignment is not known, 16-byte memory accesses may provide better
performance.
rdar://11076953
llvm-svn: 153091
|
| |
|
|
|
|
| |
(GNUstep runtime).
llvm-svn: 153090
|
| |
|
|
|
|
| |
checker working with inlined C++ template functions.
llvm-svn: 153069
|
| |
|
|
|
|
|
| |
on code using multi-dimensional arrays. Fix by DeLesley Hutchins, and reported in
PR 12271.
llvm-svn: 153067
|
| |
|
|
|
|
|
|
| |
the passed cursor is the translation unit cursor.
Patch by Clint Caywood!
llvm-svn: 153062
|
| |
|
|
| |
llvm-svn: 153052
|
| |
|
|
| |
llvm-svn: 153048
|
| |
|
|
| |
llvm-svn: 153046
|
| |
|
|
| |
llvm-svn: 153044
|
| |
|
|
|
|
| |
declaration and its siblings.
llvm-svn: 153043
|
| |
|
|
|
|
| |
On Win32 hosts, ';' is used for path separator.
llvm-svn: 153037
|
| |
|
|
|
|
|
|
| |
separate paths.
This regressed in r152583. Also add a test to make sure it doesn't regress again.
llvm-svn: 153034
|
| |
|
|
|
|
| |
arguments.
llvm-svn: 153026
|
| |
|
|
| |
llvm-svn: 153012
|
| |
|
|
|
|
|
|
|
|
| |
the realloc call and the null check, so we get nicer path notes. Fixes a regression introduced by the diagnostic pruning added in r152361.
This is accomplished by calling markInteresting /during/ path diagnostic generation, and as such relies on deterministic ordering of BugReporterVisitors -- namely, that BugReporterVisitors are run in /reverse/ order from how they are added. (Right now that's a consequence of storing visitors in an ImmutableList, where new items are added to the front.) It's a little hacky, but it works for now.
I think this is the best we can do without storing the relation between the old and new symbols, and that would be a hit whether or not there ends up being an error.
llvm-svn: 153010
|
| |
|
|
| |
llvm-svn: 153009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of suggesting " = 0" for "char c();", suggest " = '\0'", and similarly
for other char types (wide, 16, and 32). Add tests for all these, and since
this means testing such hints under C++0x, add tests for some untested C++0x
hint cases in the existing code, including suggesting nullptr for pointer
initialization.
This sets up the initialization helper to provide better type fidelity that
will be especially helpful for non-assignment cases (such as fixit-correcting
NULL usage in function calls (eg: foo(char) + foo(NULL) => foo('\0') instead
of the less informative foo(0)))
llvm-svn: 153008
|
| |
|
|
|
|
|
|
|
|
| |
than explicitly keeping DoNothing and StopTracking summaries and nothing else.
I tried to test the effects of this change on memory usage and run time, but what I saw on retain-release.m was indistinguishable from noise (debug and release builds). Even so, some caveman profiling showed 101 cache hits that we would have generated new summaries for before (i.e. not default or stop summaries), and the more code we analyze, the more memory we should save.
Maybe we should have a standard project for benchmarking the retain count checker's memory and time?
llvm-svn: 153007
|
| |
|
|
|
|
| |
nested-name-specifier for a class template declaration. Fixes PR12291.
llvm-svn: 153006
|