bhushan updated this revision to Diff 45364.
bhushan added a comment.
As suggested by Greg, added new function `matchArchitectures(archs)` which
handles "archs".
This function can be used by other decorator functions for testing "archs".
Repository:
rL LLVM
http://reviews.llvm.org/D16049
Fi
Author: ewancrawford
Date: Wed Jan 20 06:03:29 2016
New Revision: 258303
URL: http://llvm.org/viewvc/llvm-project?rev=258303&view=rev
Log:
[RenderScript] New command for viewing coordinate of current kernel invocation
Patch adds command 'language renderscript kernel coordinate' for printing the
Author: labath
Date: Wed Jan 20 06:09:12 2016
New Revision: 258304
URL: http://llvm.org/viewvc/llvm-project?rev=258304&view=rev
Log:
Enable TestConcurrentEvents on i386 linux
The test has been passing reliably the last 100 runs of the build bot.
Modified:
lldb/trunk/packages/Python/lldbsuit
Author: labath
Date: Wed Jan 20 06:17:26 2016
New Revision: 258305
URL: http://llvm.org/viewvc/llvm-project?rev=258305&view=rev
Log:
Enable TestInlineStepping on linux i386
Test has been passing at least the last 200 buildbot runs.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functio
Author: labath
Date: Wed Jan 20 06:23:23 2016
New Revision: 258306
URL: http://llvm.org/viewvc/llvm-project?rev=258306&view=rev
Log:
Fix clang warning in RenderScriptRuntime
std::array should have "the same semantics as a struct holding a C-style array
T[N] as its only
non-static data member", s
labath added a comment.
Zachary, could you take a look at this please. I'd like to squeeze this into
3.8 if it is working..
> At some point lldb-argdumper is planned to be reworked just slightly so it
> had no dependencies on the lldb core. (That would have avoided this I
> suspect.)
It woul
Author: omjavaid
Date: Wed Jan 20 09:01:54 2016
New Revision: 258315
URL: http://llvm.org/viewvc/llvm-project?rev=258315&view=rev
Log:
Mark arm/aarch64 specific xfails with expectedFailureLinux decorator
This patch marks some known failures and puts on expectedFailureLinux decorator
to have test
zturner added a comment.
I get linker errors on Windows with this. The reason is that Windows doesn't
have getopt, but getopt is called from from Driver.cpp and linked into the main
lldb executable. Since liblldb is built as a shared library, when the keyword
is public it's linking the liblld
zturner added a comment.
FWIW, I think Adrian's original point is that testing the behavior of signed
types shouldn't depend on step over functionality. It's good practice in
general to make tests depend on as little debugger functionality as possibly to
reliably test the thing you want to tes
tberghammer added a subscriber: tberghammer.
tberghammer added a comment.
In http://reviews.llvm.org/D16334#331318, @zturner wrote:
> FWIW, I think Adrian's original point is that testing the behavior of signed
> types shouldn't depend on step over functionality. It's good practice in
> genera
I sort of agree with this and sort of don't. Formally, I agree with the notion
of limited focused tests. But in practice it is often the noise in tests that
catches bugs that we don't yet have tests for. And especially when the "noise"
is doing things like step over that 100% should work in a
jingham added a comment.
I sort of agree with this and sort of don't. Formally, I agree with the notion
of limited focused tests. But in practice it is often the noise in tests that
catches bugs that we don't yet have tests for. And especially when the "noise"
is doing things like step over
zturner added a comment.
In http://reviews.llvm.org/D16334#331338, @jingham wrote:
> I sort of agree with this and sort of don't. Formally, I agree with the
> notion of limited focused tests. But in practice it is often the noise in
> tests that catches bugs that we don't yet have tests for.
zturner added a comment.
For example, what if someone adds a test that uses a very small amount of
functionality but tests the thing it's supposed to test. Do we block the
change and say "please make this test more complicated, we want to test as much
stuff as possible"? Of course not. It's
I think to get a very good coverage for the basic functionalities we need
some sort of stress testing or fuzzing infrastructure because the most
issues I hit come from compilers generating something a bit different then
we are expecting. For stack unwinding I added a stress test
(TestStandardUnwind
tberghammer added a comment.
I think to get a very good coverage for the basic functionalities we need
some sort of stress testing or fuzzing infrastructure because the most
issues I hit come from compilers generating something a bit different then
we are expecting. For stack unwinding I added a s
> On Jan 20, 2016, at 11:25 AM, Zachary Turner wrote:
>
> zturner added a comment.
>
> For example, what if someone adds a test that uses a very small amount of
> functionality but tests the thing it's supposed to test. Do we block the
> change and say "please make this test more complicated
amccarth added a comment.
By having tests doing too much, we get problems like this (where ~12 seemingly
unrelated tests started failing over the holiday weekend) instead of one test
that points to the root cause. (In this case, we're still looking for the root
cause of the regression. A simp
zturner added a comment.
I don't know, I still disagree. If something in step-over breaks, I dont' want
to dig through a list of 30 other tests that have nothing to do with the
problem, only to find out 2 days later that the problem is actually in step
over. The only reason this helps is beca
On Wed, Jan 20, 2016 at 11:48 AM Zachary Turner wrote:
>
> If the problem is that people don't have the time because they've got too
> much other stuff on their plate, that's not a good excuse and I don't think
> we should intentionally encourage writing poor tests just because someone's
> manage
Perhaps a middle ground to these two sides could be something along the
lines of "If you're going to make sweeping changes to remove a particular
feature from a set of tests, make sure there's a reasonable amount of
isolated coverage of the thing you're removing".
Honestly though, our culture of t
tberghammer added a comment.
In http://reviews.llvm.org/D16334#331368, @zturner wrote:
> I don't know, I still disagree. If something in step-over breaks, I dont'
> want to dig through a list of 30 other tests that have nothing to do with the
> problem, only to find out 2 days later that the p
zturner added a subscriber: zturner.
zturner added a comment.
Perhaps a middle ground to these two sides could be something along the
lines of "If you're going to make sweeping changes to remove a particular
feature from a set of tests, make sure there's a reasonable amount of
isolated coverage of
zturner added a comment.
In http://reviews.llvm.org/D16334#331420, @tberghammer wrote:
> In http://reviews.llvm.org/D16334#331368, @zturner wrote:
>
> > I don't know, I still disagree. If something in step-over breaks, I dont'
> > want to dig through a list of 30 other tests that have nothing t
zturner added a comment.
In http://reviews.llvm.org/D16334#331420, @tberghammer wrote:
> It is true that every CL can be tested but a lot of change is going in to
> address a specific edge case generated by a specific compiler in a strange
> situation. To create a reliable test from it we have
Hello everyone,
Below are some buildbot numbers for the last week of 1/10/2016 - 1/16/2016.
Thanks
Galina
Number of commits by project:
project | commits
---+---
llvm | 391
cfe | 100
Author: spyffe
Date: Wed Jan 20 17:12:39 2016
New Revision: 258365
URL: http://llvm.org/viewvc/llvm-project?rev=258365&view=rev
Log:
Fixed some #ifdefs. We were erroneously not supporting certain simulators.
We had some #ifdefs that were looking for the wrong #defines and as a result
debugserver
Author: enrico
Date: Wed Jan 20 17:20:10 2016
New Revision: 258367
URL: http://llvm.org/viewvc/llvm-project?rev=258367&view=rev
Log:
Fix a problem where we were not calling fcntl() with the correct arguments for
F_DUPFD
On Mac OS X, this was working just fine in debug builds (presumably, because
Author: jmolenda
Date: Wed Jan 20 22:38:05 2016
New Revision: 258387
URL: http://llvm.org/viewvc/llvm-project?rev=258387&view=rev
Log:
When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,
set the triple's "vendor" field to Apple.
We don't want to assume a vendor of Apple for all Mach-
29 matches
Mail list logo
