Go compiler tests?

256 views
Skip to first unread message

Steven Johnson

unread,
Apr 5, 2012, 1:08:43 PM4/5/12
to golan...@googlegroups.com
> The semantics are in the specs. Either the code follows the specs or not.
> It's not a question of anyone's opinion (modulo occasional corner cases
> discovered to be not yet defined, like
> e.g. http://code.google.com/p/go/issues/detail?id=3464).

(Threadjacked from GoScript discussion)

So is there a standard self-test suite that alternate Go compilers
(eg, GoScript, llvmgo) can use to verify conformance?

minux

unread,
Apr 5, 2012, 1:27:16 PM4/5/12
to Steven Johnson, golan...@googlegroups.com
the test directory in go repository contain many compiler tests.

Jan Mercl

unread,
Apr 5, 2012, 4:27:12 PM4/5/12
to golan...@googlegroups.com
Such [full coverage] test suite, ideally verifying at least every single semantic "atom" of the Go specs, is a dream project, I guess, as it is probably too costly for any single volunteer to complete [in free time]. However, as a community project, it might be both feasible (on the "longer" run) and also quite valuable, perhaps even having a potential to positively influence Go future perspectives...?

Ian Lance Taylor

unread,
Apr 5, 2012, 6:40:13 PM4/5/12
to Steven Johnson, golan...@googlegroups.com
Steven Johnson <s...@google.com> writes:

> So is there a standard self-test suite that alternate Go compilers
> (eg, GoScript, llvmgo) can use to verify conformance?

The contents of go/test, particularly go/test/fixedbugs, include all the
cases we've discovered where either of the main Go compilers mishandled
valid code.

The less common areas in Go have extensive tests in go/test (e.g.,
go/test/shift[12].go, go/test/interface/*.go, go/test/chan/*.go, etc.).

That said, there has been no attempt to systematically go through the
spec and test every aspect of it.

Ian

Andrew Wilkins

unread,
Apr 5, 2012, 10:25:07 PM4/5/12
to golan...@googlegroups.com
On Friday, 6 April 2012 01:08:43 UTC+8, Steven Johnson wrote:

So is there a standard self-test suite that alternate Go compilers
(eg, GoScript, llvmgo) can use to verify conformance? 

I'm in the process of putting together automated functional tests for llgo.

It's pretty basic at the moment: each test case is a standalone program
that is run once with "go run", and then compiled & interpreted with
llgo/gollvm and the output compared. Usually straight equality, but
sometimes there's some non-determinism (or rather, unspecified order),
e.g. order of "init" functions.

The intention is to test the entire spec, though I am but one person
doing this in my free time. There aren't very many test cases yet, either,
but I'll try to keep in mind as I go on the possibility of pulling the test
cases out into an independent project.

Cheers,
Andrew

Sebastien Binet

unread,
Apr 6, 2012, 4:46:57 AM4/6/12
to Andrew Wilkins, golan...@googlegroups.com
Andrew Wilkins <axw...@gmail.com> writes:

> On Friday, 6 April 2012 01:08:43 UTC+8, Steven Johnson wrote:
>>
>> So is there a standard self-test suite that alternate Go compilers
>> (eg, GoScript, llvmgo) can use to verify conformance?
>>
> I'm in the process of putting together automated functional tests for llgo.
>
> It's pretty basic at the moment: each test case is a standalone program
> that is run once with "go run", and then compiled & interpreted with
> llgo/gollvm and the output compared.

interpreted ?
did you use/write an interpreter (like cling for clang) ?

(I wanted to work on llgo but gollvm requires the not yet released
llvm-3.1...)

-s

Andrew Wilkins

unread,
Apr 6, 2012, 7:23:49 AM4/6/12
to golan...@googlegroups.com, Andrew Wilkins, seb....@gmail.com
On Friday, 6 April 2012 16:46:57 UTC+8, Sebastien Binet wrote:

> It's pretty basic at the moment: each test case is a standalone program
> that is run once with "go run", and then compiled & interpreted with
> llgo/gollvm and the output compared.

interpreted ?
did you use/write an interpreter (like cling for clang) ?

No, sorry, what I meant was that the source is compiled to LLVM bitcode,
and then the bitcode is interpreted using LLVM's bitcode interpreter. Think
JIT, but without dynamic machine code translation.
 

(I wanted to work on llgo but gollvm requires the not yet released
llvm-3.1...)

Help would be welcome. LLVM 3.1 is due out on May 14, so still a little
while away. If you want to get involved earlier, you can build gollvm (my
fork) with LLVM's trunk. Feel free to email me off-list for further info.

Cheers,
Andrew

Steven Johnson

unread,
Apr 6, 2012, 4:12:38 PM4/6/12
to Andrew Wilkins, golan...@googlegroups.com
On Thu, Apr 5, 2012 at 7:25 PM, Andrew Wilkins <axw...@gmail.com> wrote:
> The intention is to test the entire spec, though I am but one person
> doing this in my free time. There aren't very many test cases yet, either,
> but I'll try to keep in mind as I go on the possibility of pulling the test
> cases out into an independent project.

Excellent. I'll add your project to my watchlist :-)

Reply all
Reply to author
Forward
0 new messages