Yes, I have other options, I just wanted to verify that this was still
your answer.
Thanks.
On 01/14/2015 09:24 AM, Ian Lance Taylor wrote:
On Wed, Jan 14, 2015 at 5:49 AM, Lynn A. Boger
wrote:
I have an updated patch for the reflection functions in gcc 4.9 for ppc64 &
ppc64le which allows t
On Wed, Jan 14, 2015 at 5:49 AM, Lynn A. Boger
wrote:
> I have an updated patch for the reflection functions in gcc 4.9 for ppc64 &
> ppc64le which allows the recover.go test to pass and the updated version of
> libgo/go/reflect/all_tests.go to pass once all testcases are enabled for
> ppc64 & ppc
I have an updated patch for the reflection functions in gcc 4.9 for
ppc64 & ppc64le which allows the recover.go test to pass and the updated
version of libgo/go/reflect/all_tests.go to pass once all testcases are
enabled for ppc64 & ppc64le.
Based on the discussion we've had on this patch, has
The only bugs I am aware of when using reflection on ppc64 & ppc64le in
gcc 4.9 are in the gccgo testcase recover.go and what is needed to build
Docker. When I run the gccgo testsuite and see a failing testcase with
a panic message saying that a function is not implemented it makes me
think so
On Thu, Jan 8, 2015 at 5:44 AM, Lynn A. Boger
wrote:
>
> Also as was noted below, some level of reflection support is needed to build
> Docker.
Sorry to be so pedantic, but I'm just trying to clarify that you keep
saying "reflection support," but reflection support is there. What is
missing is a
If this change is not included, in the gcc go testsuite, the recover.go
testcase fails with this error:
panic: reflect.makeMethodValue not implemented for ppc64le
when running this test:
func test9reflect1() {
f := reflect.ValueOf(&T1{}).Method(0).Interface().(func())
defer f()
On Wed, Jan 7, 2015 at 4:39 PM, Michael Hudson-Doyle
wrote:
> Ian Lance Taylor writes:
>
>> On Wed, Jan 7, 2015 at 9:26 AM, Lynn A. Boger
>> wrote:
>>>
>>> In libgo/go/reflect/makefunc.go, calls to MakeFunc, makeMethodValue and
>>> makeValueMethod will panic if called when GOARCH is ppc64 or ppc
Ian Lance Taylor writes:
> On Wed, Jan 7, 2015 at 9:26 AM, Lynn A. Boger
> wrote:
>>
>> In libgo/go/reflect/makefunc.go, calls to MakeFunc, makeMethodValue and
>> makeValueMethod will panic if called when GOARCH is ppc64 or ppc64le.
>
> Right, I'm just saying that almost no code actually does th
On Wed, Jan 7, 2015 at 9:26 AM, Lynn A. Boger
wrote:
>
> In libgo/go/reflect/makefunc.go, calls to MakeFunc, makeMethodValue and
> makeValueMethod will panic if called when GOARCH is ppc64 or ppc64le.
Right, I'm just saying that almost no code actually does that. I just
tried a web search and fo
In libgo/go/reflect/makefunc.go, calls to MakeFunc, makeMethodValue and
makeValueMethod will panic if called when GOARCH is ppc64 or ppc64le.
I understand your point about what you allow into a release branch and
since it has known bugs with an existing testcase then I agree it
shouldn't be ac
On Wed, Jan 7, 2015 at 8:43 AM, Lynn A. Boger
wrote:
>
> I thought that since this only affects ppc64 and ppc64le, and provides
> reflection support that doesnt exist in gcc 4.9 for Power (you get a panic
> if you try to use reflection on ppc64, ppc64le), it would be OK.
I understand that the cod
I thought that since this only affects ppc64 and ppc64le, and provides
reflection support that doesnt exist in gcc 4.9 for Power (you get a
panic if you try to use reflection on ppc64, ppc64le), it would be OK.
We'll look at putting it in our own branch.
On 01/07/2015 10:06 AM, Ian Lance Taylo
On Tue, Jan 6, 2015 at 7:37 AM, Lynn A. Boger
wrote:
> Add support for reflection for gccgo in gcc 4.9. This is not a backport
> because reflection support in gcc trunk is done using FFI. Bootstrap built
> and tested on ppc64, ppc64le.
Sorry, I didn't see at first that this is not a backport. T
13 matches
Mail list logo
