On 11/26/2015 05:37 AM, Bernd Schmidt wrote:
On 11/25/2015 11:47 PM, David Malcolm wrote:
FWIW, the reason I special-cased the linked list was to avoid any
dynamic memory allocation: the ctors run before main, so I wanted to
keep them as simple as possible.
Is there any particular reason for t
On 11/25/2015 09:50 AM, Mike Stump wrote:
On Nov 25, 2015, at 2:55 AM, Bernd Schmidt wrote:
That would be the ideal - though do we require randomization
What do you hope to gain with randomization?
Please, no randomization.
Agreed.
However, from a design standpoint, the tests must not de
On 11/25/2015 11:47 PM, David Malcolm wrote:
FWIW, the reason I special-cased the linked list was to avoid any
dynamic memory allocation: the ctors run before main, so I wanted to
keep them as simple as possible.
Is there any particular reason for this? C++ doesn't disallow memory
allocation i
On Wed, 2015-11-25 at 11:55 +0100, Bernd Schmidt wrote:
> On 11/25/2015 03:26 AM, David Malcolm wrote:
> > Consider the case where an assumption that the host is little-endian
> > assumption creeps into one of the bitmap functions. Some time later,
> > another developer updates their working copy
On Thu, 2015-11-19 at 19:44 +0100, Bernd Schmidt wrote:
> On 11/19/2015 07:08 PM, David Malcolm wrote:
> > gcc_assert terminates the process and no further testing is done,
> > whereas the approach the kit tries to run as much of the testsuite as
> > possible, and then fail if any errors occurred.
On Nov 25, 2015, at 2:55 AM, Bernd Schmidt wrote:
>> That would be the ideal - though do we require randomization
> What do you hope to gain with randomization?
Please, no randomization.
On 11/25/2015 03:26 AM, David Malcolm wrote:
Consider the case where an assumption that the host is little-endian
assumption creeps into one of the bitmap functions. Some time later,
another developer updates their working copy from svn on a big-endian
host and finds that lots of things are brok
On Tue, Nov 24, 2015 at 01:44:34PM -0700, Jeff Law wrote:
> On 11/19/2015 11:44 AM, Bernd Schmidt wrote:
> >On 11/19/2015 07:08 PM, David Malcolm wrote:
> >>gcc_assert terminates the process and no further testing is done,
> >>whereas the approach the kit tries to run as much of the testsuite as
>
On Tue, 2015-11-24 at 13:44 -0700, Jeff Law wrote:
> On 11/19/2015 11:44 AM, Bernd Schmidt wrote:
> > On 11/19/2015 07:08 PM, David Malcolm wrote:
> >> gcc_assert terminates the process and no further testing is done,
> >> whereas the approach the kit tries to run as much of the testsuite as
> >> p
On 11/19/2015 10:04 AM, David Malcolm wrote:
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though without the use of CamelCase): it
supports enough of the gtest API to enable the tests that I
wrote to run with minimal changes.
I know it's small, but avoiding Came
On 11/19/2015 11:44 AM, Bernd Schmidt wrote:
On 11/19/2015 07:08 PM, David Malcolm wrote:
gcc_assert terminates the process and no further testing is done,
whereas the approach the kit tries to run as much of the testsuite as
possible, and then fail if any errors occurred.
Yeah, but let's say
On 11/19/2015 10:35 AM, Bernd Schmidt wrote:
In general I'm much happier with this approach, and I think this series
is close to ready, but I want to bring up some questions that could use
wider discussion.
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though wi
On 11/19/2015 09:44 PM, Bernd Schmidt wrote:
> It's one option, but it doesn't seem like the best one either. I was
> thinking of something not dissimilar to your approach, but with fewer
> bells and whistles. My class registrator would look something like this:
>
> static list test_callbacks;
>
On 11/19/2015 07:08 PM, David Malcolm wrote:
gcc_assert terminates the process and no further testing is done,
whereas the approach the kit tries to run as much of the testsuite as
possible, and then fail if any errors occurred.
Yeah, but let's say someone is working on bitmaps and one of the b
On Nov 19, 2015, at 10:08 AM, David Malcolm wrote:
> gcc_assert terminates the process and no further testing is done,
> whereas the approach the kit tries to run as much of the testsuite as
> possible, and then fail if any errors occurred.
Running as much as possible is desirable over stopping a
On Thu, 2015-11-19 at 18:35 +0100, Bernd Schmidt wrote:
> In general I'm much happier with this approach, and I think this series
> is close to ready, but I want to bring up some questions that could use
> wider discussion.
> > This patch adds a selftest.h/.c to gcc, with an API loosely
> > mode
In general I'm much happier with this approach, and I think this series
is close to ready, but I want to bring up some questions that could use
wider discussion.
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though without the use of CamelCase): it
supports eno
This is effectively v4 of the unittests proposal; for the earlier
versions see:
* v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
* v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
* v3: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02947.html
This patch adds a selftest
18 matches
Mail list logo
