Go compiler tests?

[Steven Johnson]

> 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]

the test directory in go repository contain many compiler tests.

[Jan Mercl]

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]

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]

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]

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]

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]

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 :-)