On 11/17/2015 05:51 AM, Bernd Schmidt wrote:
On 11/17/2015 02:53 AM, Mike Stump wrote:
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
So I'd tend to want them either at the end of the file with a
single #if CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files muc
On 11/17/2015 02:53 AM, Mike Stump wrote:
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
So I'd tend to want them either at the end of the file with a
single #if CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files mucked up with tests. I
think I’d rather have
#
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
> So I'd tend to want them either at the end of the file with a single #if
> CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files mucked up with tests. I think I’d
rather have
#if CHECKING_P
#include "test/expr-test.h
On 11/16/2015 11:48 AM, David Malcolm wrote:
For some of the simpler infrastructure tests such as the ones in this
patch kit (bitmap, vec or wide-int functionality testing and such), we
had the idea of putting these into every ENABLE_CHECKING compiler, and
run them after building stage1, control
For some of the simpler infrastructure tests such as the ones in this
patch kit (bitmap, vec or wide-int functionality testing and such), we
had the idea of putting these into every ENABLE_CHECKING compiler, and
run them after building stage1, controlled by a -fself-test flag. It's
better to det
On Mon, 2015-11-16 at 19:17 +0100, Bernd Schmidt wrote:
> So Jeff and I just had a chat, and we came up with some thoughts about
> how to proceed. I think we both agree that it would be good to have a
> special testing backend, along with frontends designed to be able to
> read in gimple or rtl
So Jeff and I just had a chat, and we came up with some thoughts about
how to proceed. I think we both agree that it would be good to have a
special testing backend, along with frontends designed to be able to
read in gimple or rtl that can be operated on. That's more of a
long-term thing.
Fo
On 10/30/2015 04:54 AM, Bernd Schmidt wrote:
The counter is that when grepping, you should probably be using
find/xargs grep :-)
There's actually a tool called ack which automates that. But we've often
seen cases where people fail to spot occurrences in config/ directories.
We certainly have.
On 10/29/2015 08:21 PM, Jeff Law wrote:
Excellent point. I think this is worth some serious thought. Given the
state of GCC's sources, tests of this nature are going to be inherently
tied to implementation details/sources rather than interfaces. That's
obviously not ideal, but it is where we a
On 10/27/2015 01:58 PM, David Malcolm wrote:
On Tue, 2015-10-27 at 15:48 -0400, David Malcolm wrote:
[...snip...]
Looks like [Patch 02/16] was too big (1.2MB) for the list;
it can be seen here:
https://dmalcolm.fedorapeople.org/gcc/2015-10-27/unittests/0002-Add-embedded-copy-of-gtest-1.7-to-unit
On 10/29/2015 04:22 PM, Mike Stump wrote:
On Oct 29, 2015, at 12:32 PM, Jeff Law wrote:
Something similar for RTL would be cool, but probably even harder
given the amount of state that's traditionally been kept out of the
IL stream. I'm sure some things are better today than in the past,
but i
On Oct 29, 2015, at 12:32 PM, Jeff Law wrote:
> Something similar for RTL would be cool, but probably even harder given the
> amount of state that's traditionally been kept out of the IL stream. I'm
> sure some things are better today than in the past, but it's probably a very
> tanged mess to
On 10/29/2015 10:10 AM, David Malcolm wrote:
There may be useful things in gtest for us that I'm not using yet. For
example, the support for death tests may be useful for testing that e.g.
our checking macros kill the program sanely in the presence of malformed
internal data.
Please check on th
On 10/28/2015 05:38 AM, Bernd Schmidt wrote:
On 10/27/2015 08:48 PM, David Malcolm wrote:
The following patch kit adds a unit tests framework for gcc,
as a new subdirectory below gcc/testsuite.
So, as a general comment I think this would be a very good thing to
have, and from a quick look thro
On Wed, 2015-10-28 at 12:38 +0100, Bernd Schmidt wrote:
> On 10/27/2015 08:48 PM, David Malcolm wrote:
> > The following patch kit adds a unit tests framework for gcc,
> > as a new subdirectory below gcc/testsuite.
>
> So, as a general comment I think this would be a very good thing to
> have, an
On Oct 27, 2015, at 12:48 PM, David Malcolm wrote:
> The following patch kit adds a unit tests framework for gcc,
I’m supportive of the patch set and the concept in general. I don’t know who
wants to review this, Jeff seems on track to do this. My only guidance would
be to say we should allow
On 10/27/2015 01:48 PM, David Malcolm wrote:
This is a followup to these proposals:
* v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
* v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
The following patch kit adds a unit tests framework for gcc,
as a new subdirectory
On 10/28/2015 12:38 PM, Bernd Schmidt wrote:
* This uses a plugin into whatever compiler was built, but sometimes
you can't really set up unit tests that way because what you want
to test depends on target specifics. What I've often wanted is a
special test target that gets built wi
On 10/27/2015 08:48 PM, David Malcolm wrote:
The following patch kit adds a unit tests framework for gcc,
as a new subdirectory below gcc/testsuite.
So, as a general comment I think this would be a very good thing to
have, and from a quick look through the tests they look pretty sensible.
L
On Tue, 2015-10-27 at 15:48 -0400, David Malcolm wrote:
[...snip...]
Looks like [Patch 02/16] was too big (1.2MB) for the list;
it can be seen here:
https://dmalcolm.fedorapeople.org/gcc/2015-10-27/unittests/0002-Add-embedded-copy-of-gtest-1.7-to-unittests.patch
[..snip...]
20 matches
Mail list logo
