On 17/01/14 23:56, Michael Hudson-Doyle wrote:
> Ian Lance Taylor <i...@golang.org> writes:
>
>> On Fri, Jan 17, 2014 at 11:32 AM, Michael Hudson-Doyle
>> <michael.hud...@canonical.com> wrote:
>>>
>>> On 18 Jan 2014 07:50, "Yufeng Zhang" <yufeng.zh...@arm.com> wrote:
>>>>
>>>> Also can you please try to add some new test(s)? It may not be that
>>>> straightforward to add non-C/C++ tests, but give it a try.
>>>
>>> Can you give some hints? Like at least where in the tree such a test would
>>> go? I don't know this code at all.
>>
>> There is already a test in libgo, of course.
>>
>> I think it would be pretty hard to write a test that doesn't something
>> like what libgo does. The problem is that GCC is entirely consistent
>> with and without your patch. You could add a Go test that passes an
>> array in gcc/testsuite/go.go-torture/execute/ easily enough, but it
>> would be quite hard to add a test that doesn't pass whether or not
>> your patch is applied.
>
> I think it would have to be a code generation test, i.e. that compiling
> something like
>
> func second(e [2]int64) int64 {
> return e[1]
> }
>
> does not access memory or something along those lines. I'll have a look
> next week.
>
> Cheers,
> mwh
>
Michael,
Can you have a look at how the tests in gcc.target/aarch64/aapcs64 work;
it ought to be possible to write a test (though not in C) to catch this.
The tests work by calling a wrapper function written in assembler --
that wrapper stores out all the registers used for parameter passing and
then calls back into the test's validator with the register dump
available. Code can then check that values are passed in the places
expected. This gives the compiler the separation between caller and
callee that's needed to test this feature.
My preferred languages for these tests would be (in approximate order)
c, c++, fortran, java, ada, go. That order is based on which languages
are tested most by users.
R.
