| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Clang rejects __attribute__((regparm)) when targetting arm. The default
calling convention passes arguments in registers anyway, so we can just
remove them in this case.
llvm-svn: 300670
|
|
|
|
| |
llvm-svn: 300519
|
|
|
|
| |
llvm-svn: 300517
|
|
|
|
|
|
|
| |
LDFLAGS contains some .a files. If it is specified before the relevant
object files, undefined symbol errors occur.
llvm-svn: 300048
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug introduced by r291559. The Module's FindType was
passing the original name not the basename in the case where it didn't
find any separators. I also added a testcase for this.
<rdar://problem/31159173>
llvm-svn: 298331
|
|
|
|
|
|
|
|
|
| |
We are going to turn off buffer overflow introduced by gcc by turning off
FORTIFY_SOURCE.
Differential revision: https://reviews.llvm.org/D28666
llvm-svn: 291949
|
|
|
|
|
|
|
| |
I have previously enabled this test for this configuration. However, it turns
out it only passes for gcc-4.9.
llvm-svn: 291563
|
|
|
|
|
|
|
|
|
|
| |
empty objective C types from the runtime.
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message
Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array
error: warning: expression result unused
error: The expression could not be prepared to run in the target
This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase.
https://reviews.llvm.org/D27291
<rdar://problem/13190557>
llvm-svn: 288386
|
|
|
|
|
|
| |
The test has been passing for a while now.
llvm-svn: 287884
|
|
|
|
|
|
| |
It consistently passes for linux-clang-i386, and linux-gcc-x86_64.
llvm-svn: 287883
|
|
|
|
|
|
|
|
| |
Fails with all versions of arm/aarch64 gcc available on ubuntu 16.04/14.04.
Passes with Linaro GCC version >= 4.8 but fails with >= 5.0. But There are other regressions when we use Linaro GCC.
llvm-svn: 286574
|
|
|
|
| |
llvm-svn: 286476
|
|
|
|
|
|
|
|
| |
The debug info emitted by clang for static variables improved by
rL286302 and it exposed an incorrect test expactation because now LLDB
able to displays more data 9thanks to better debug info) then before.
llvm-svn: 286360
|
|
|
|
|
|
|
|
| |
though the user asked for it
Part of rdar://28434047
llvm-svn: 285226
|
|
|
|
|
|
|
| |
Fixes:
rdar://27792848
llvm-svn: 285032
|
|
|
|
|
|
| |
used platform.release
llvm-svn: 284674
|
|
|
|
| |
llvm-svn: 284448
|
|
|
|
| |
llvm-svn: 284446
|
|
|
|
| |
llvm-svn: 284296
|
|
|
|
| |
llvm-svn: 284183
|
|
|
|
| |
llvm-svn: 284182
|
|
|
|
| |
llvm-svn: 283959
|
|
|
|
| |
llvm-svn: 283957
|
|
|
|
| |
llvm-svn: 283956
|
|
|
|
| |
llvm-svn: 283843
|
|
|
|
| |
llvm-svn: 283578
|
|
|
|
|
|
| |
Xfails added and/or removed to reflect the current state of Windows.
llvm-svn: 283380
|
|
|
|
|
|
|
| |
worth preserving, but not essential to the purpose of this test
so I broke it into a separate test.
llvm-svn: 283289
|
|
|
|
|
|
| |
and that is defeating the lookup of the "struct C" here. Adding the bug for that.
llvm-svn: 283287
|
|
|
|
| |
llvm-svn: 282869
|
|
|
|
|
|
|
|
| |
doesn't
I can't reproduce locally. Hopefully this will help us catch the reason.
llvm-svn: 282810
|
|
|
|
| |
llvm-svn: 282794
|
|
|
|
| |
llvm-svn: 282787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
|
|
| |
Reports an error instead. We can fix this later to make persistent variables
work, but right now we hit an LLVM assertion if we get this wrong.
<rdar://problem/27770298>
llvm-svn: 279850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
them.
Clang on ARM64 was making the three Function methods with identical bodies have
one implementation that was shared. That threw off the count of breakpoints, since
we don't count as separate locations three functions with the same address.
I also cleaned up the test case while I was at it.
<rdar://problem/27001915>
llvm-svn: 279800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
referencing a user-defined operator new was triggering an assert in clang because we were
registering the function name as string "operator new", instead of using the special operator
enum, which clang has for this purpose. Method operators already had code to handle this, and now
I extend this to cover free standing operator functions as well. Test included.
Reviewers: spyffe
Subscribers: sivachandra, paulherman, lldb-commits
Differential Revision: http://reviews.llvm.org/D17856
llvm-svn: 278670
|
|
|
|
| |
llvm-svn: 278491
|
|
|
|
|
|
|
| |
Tracked by:
rdar://27792848
llvm-svn: 278289
|
|
|
|
| |
llvm-svn: 278197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
|
|
|
|
|
|
|
|
| |
Added test cases to exiting tests to cover the new functionality.
<rdar://problem/24311282>
llvm-svn: 275459
|
|
|
|
| |
llvm-svn: 275394
|
|
|
|
|
|
| |
<rdar://problem/24599697>
llvm-svn: 275336
|
|
|
|
|
|
|
|
| |
Also added a testcase.
<rdar://problem/22786569>
llvm-svn: 274580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
One of the tests there does not work with gcc, so I'm spinning that off into a separate test, so
that we can XFAIL it with more granularity.
I am also renaming the test to reflect the fact that it no longer tests only integer arguments.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21923
llvm-svn: 274505
|
|
|
|
| |
llvm-svn: 274490
|
|
|
|
|
|
| |
for Darwin, always skip on windows, and expected fail for all other OSs while mentioning the new bug I filed to track fixing TLS variables: https://llvm.org/bugs/show_bug.cgi?id=28392
llvm-svn: 274393
|
|
|
|
|
|
|
|
|
|
|
| |
because there was a dectorator:
@unittest2.expectedFailure("rdar://7796742")
Which was covering up the fact this was failing on linux and hexagon. I added back a decorator so we don't break any build bots.
llvm-svn: 274388
|