Re: libgo patch committed: Update to Go1.8rc1

which one it was because libgo.so.10 could be either Go 1.7 or 1.8. Maybe nobody cares about doing that. It's not a huge deal to me but it would be a point of confusion. GCC 6.x was Go 1.6. On 01/17/2017 10:09 AM, Jakub Jelinek wrote: On Tue, Jan 17, 2017 at 10:03:25AM -0600, Lynn A. Boger

Re: libgo patch committed: Update to Go1.8rc1

I think this is missing the update of the libgo version number. - Lynn On 01/13/2017 06:05 PM, Ian Lance Taylor wrote: I committed a patch to libgo to update the library to the first release candidate of the upcoming Go 1.8 release. This is a big update, mostly a straight copy of the code in

Re: [patch v2] Get rid of stack trampolines for nested functions (1/4)

Yes I rebuilt everything and now it all looks good. The previously failing testcases are now passing and no new regressions. I must have had something set incorrectly in my environment on my first try. Thanks! On 12/06/2016 04:26 PM, Eric Botcazou wrote: I tried this patch applied

Re: [patch v2] Get rid of stack trampolines for nested functions (1/4)

I tried this patch applied against latest and it fixed the testcases that I had reported as failing, but the patch also causes libgo reflect testcase to fail. Still testing to verify and will report the failure details. On 12/06/2016 02:18 PM, Ian Lance Taylor wrote: On Tue, Dec 6, 2016

Re: [patch v2] Get rid of stack trampolines for nested functions (1/4)

I think you mean https://github.com/golang/go/issues/18200. - Lynn On 12/05/2016 02:52 PM, Ian Lance Taylor wrote: On Sun, Sep 4, 2016 at 1:10 PM, Eric Botcazou wrote: 2016-07-04 Eric Botcazou PR ada/37139 PR ada/67205

Re: libgo patch committed: Change build procedure to use build tags

libgo test results in gcc-testresults for ppc64le & ppc64 are back to what they were before the change. Thanks. On 08/08/2016 03:34 PM, Ian Lance Taylor wrote: On Mon, Aug 8, 2016 at 11:14 AM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: The libgo tests on ppc64le and ppc6

Re: libgo patch committed: Change build procedure to use build tags

just to be sure there wasn't something flaky with the system. On 08/08/2016 01:26 PM, Ian Lance Taylor wrote: On Mon, Aug 8, 2016 at 11:14 AM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: The libgo tests on ppc64le and ppc64 have all been failing in gcc-testresults since this c

Re: libgo patch committed: Change build procedure to use build tags

The libgo tests on ppc64le and ppc64 have all been failing in gcc-testresults since this change went in and continues to fail after the recent fixes for failures on other platforms. Built myself and got the same failures. I set keep=true in gotest to save the test dirs. Just running a

Re: libgo patch committed: Update to 1.7rc3

libgo version bump to indicate the change in Go version? On 07/22/2016 01:15 PM, Ian Lance Taylor wrote: I have committed a patch to update libgo to the 1.7rc3 release candidate. This is very close to the upcoming 1.7 release. As usual with libgo updates, the patch is too large to include in

Re: libgo patch committed: Update to Go 1.6rc1

Should the libgo version number be updated? On 02/03/2016 03:58 PM, Ian Lance Taylor wrote: I've committed a patch to the libgo library to update it to Go 1.6rc1, the first release candidate for the Go 1.6 release. As usual with major libgo updates, the change is too large to include here.

Re: libgo patch committed: Update to Go 1.5 release

We are seeing failures on all the libgo tests when gccgo is built with the latest trunk on ppc64 (BE) and when running the testsuite for 64 bit. The failures do not occur if run on ppc64 BE with m32 and do not occur on ppc64le. The messages say this: make[3]: Entering directory

Re: libgo patch committed: Update to Go 1.5 release

with 64 and 32 bit. On 11/03/2015 11:34 AM, Ian Lance Taylor wrote: On Tue, Nov 3, 2015 at 7:48 AM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: We are seeing failures on all the libgo tests when gccgo is built with the latest trunk on ppc64 (BE) and when running the testsuite for

Re: libgo patch committed: Update to Go 1.5 release

I see this error when building gccgo from trunk on ppc64le and running the libgo tests: exec_unix_test.go:174:43: error: reference to undefined identifier 'syscall.TIOCGPGRP' errno := syscall.Ioctl(tty.Fd(), syscall.TIOCGPGRP, uintptr(unsafe.Pointer()))

Re: libgo patch committed: Update to Go 1.5 release

I'll try it That was the only error I hit with the go and libgo tests with Go 1.5. I assume there will be a different number for the libgo.so for Go 1.5? On 11/02/2015 02:23 PM, Ian Lance Taylor wrote: On Mon, Nov 2, 2015 at 7:39 AM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wro

[PATCH] Eliminate libgo.so dependency for go and gofmt tools in gotools/

, this allows for go and gofmt to be built with a gccgo that is available during the build but then libgo.so is not a dependency when using go or gofmt once the build is finished. The cgo tool is also built here but since that is needed during compiling with gccgo I left that as is. 2015-10-16Lynn

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

at 11:25:38PM +0200, Andreas Schwab wrote: "Lynn A. Boger" <labo...@linux.vnet.ibm.com> writes: Index: gcc/config/rs6000/sysv4.h === --- gcc/config/rs6000/sysv4.h (revision 228653) +++ gcc/config/rs6000/sysv4

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

Thanks for doing this Alan. I agree this looks better to me. I assume by "etc" you mean you did biarch builds for your bootstraps on BE? On 10/11/2015 08:07 AM, Alan Modra wrote: On Sat, Oct 10, 2015 at 11:25:38PM +0200, Andreas Schwab wrote: "Lynn A. Boger" <lab

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

: On 08.10.2015 20:56, Lynn A. Boger wrote: I think my original fix with linux.h doing the #undef on TARGET_CAN_SPLIT_STACK_64BIT is the right fix at least for powerpc-linux-gnu 32 bit only. It works for powerpc-linux-gnu without multilib and doesn't break powerpc64-linux-gnu or powerpc64le-linux-gnu. Can

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

are configuring the multilib build that defaults to powerpc-linux-gnu and how it fails? Maybe there is another problem for that combination. As David noted, the use of TARGET_64BIT or TARGET_POWERPC64 won't work for this #define. On 10/07/2015 12:31 PM, Matthias Klose wrote: On 07.10.2015 17:36, Lynn

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

Any update on this patch? On 09/18/2015 07:48 AM, David Edelsohn wrote: On Thu, Sep 17, 2015 at 3:13 PM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: Here is my updated patch, with the changes suggested by Ian for gcc/gospec.c and David for gcc/configure.ac. Bootstrap built and

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

Here is my updated patch, with the changes suggested by Ian for gcc/gospec.c and David for gcc/configure.ac. Bootstrap built and tested on ppc64le, ppc64 multilib. 2015-09-17Lynn Boger <labo...@linux.vnet.ibm.com> gcc/ PR target/66870 config/rs6000/sysv4.h:

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

Edelsohn wrote: On Thu, Aug 27, 2015 at 5:00 PM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: Here is an updated patch, with a summary of the differences from my previous patch: - In my previous patch gcc configure was verifying the gold linker even if it was the default

Re: [patch] Remove unsupported hosts/builds from gcc/config.*

This patch was committed without regenerating gcc/configure. On 08/21/2015 03:10 AM, FX wrote: Attached patch removes special cases for the following unsupported targets as build and host environments: - uwin* - i370-*-opened* | i370-*-mvs* - i[34567]86-*-sco3.2v5* - i[34567]86-sequent-ptx4*

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

or the gold linker. Bootstrapped and tested on x86_64, ppc64le, ppc64 (ran m32, m64 tests) 2015-08-27Lynn Boger labo...@linux.vnet.ibm.com gcc/ PR target/66870 config/rs6000/sysv4.h: Define TARGET_CAN_SPLIT_STACK_64BIT based on LIBC version. config.in: Set up

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

I am working on a new patch to address some of the previous concerns and plan to post it soon after some final testing. On 08/25/2015 05:51 PM, Ian Lance Taylor wrote: On Tue, Aug 18, 2015 at 1:36 PM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: libgo/ PR target/66870

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

if fsplit-stack is set for all compilers, not just gccgo. On 08/19/2015 02:33 PM, Matthias Klose wrote: On 08/18/2015 10:36 PM, Lynn A. Boger wrote: As discussed in PR 66870, for ppc64le and ppc64le it is preferred to use the gold linker with gccgo or gcc if the split stack option is enabled

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

to mess up other platforms so I left those as is. On 08/19/2015 02:33 PM, Matthias Klose wrote: On 08/18/2015 10:36 PM, Lynn A. Boger wrote: As discussed in PR 66870, for ppc64le and ppc64le it is preferred to use the gold linker with gccgo or gcc if the split stack option is enabled. Use

[PATCH] PR66870 PowerPC64 Enable gold linker with split stack

stack work as before. 2015-08-18Lynn Boger labo...@linux.vnet.ibm.com gcc/ PR target/66870 config/rs6000/linux64.h: When HAVE_LD_GOLD_SUPPORTS_SPLIT_STACK is defined add -fuse-ld=gold if fsplit-stack and not m32 config/rs6000/sysv4.h: Define

[PATCH] Fix PR66870 ppc64le, ppc64 split stack

, passed the go and libgo testsuites (where split stack is enabled by default). gcc/ChangeLog 2015-07-30Lynn Boger labo...@linux.vnet.ibm.com PR66870 * gcc/config/rs6000/rs6000.c: Add check for no_split_stack function attribute along

Re: [Patch 0/4] PowerPC64 Linux split stack support

Can this patch be submitted to fix the ppc 32 bootstrap error? On 06/19/2015 07:58 AM, Andreas Schwab wrote: * go-lang.c (go_langhook_init_options_struct): Don't set x_flag_split_stack. (go_langhook_post_options): Set it here instead. --- gcc/go/go-lang.c | 9 +

Re: [Patch 0/4] PowerPC64 Linux split stack support

I have tested this and it fixes the problem. On 07/01/2015 09:15 AM, Andreas Schwab wrote: Lynn A. Boger labo...@linux.vnet.ibm.com writes: It's not clear to me what distro/gcc/glibc versions and type of build causes the error. I have not been able to reproduce the original problem

Re: [Patch 0/4] PowerPC64 Linux split stack support

If further testing is needed on this patch I can do it, but I need more information what variations need to be tested? It's not clear to me what distro/gcc/glibc versions and type of build causes the error. I have not been able to reproduce the original problem. On 06/15/2015 01:58 PM,

Re: [gofrontend-dev] Re: GO tools for gccgo cross

On 05/22/2015 05:50 PM, Ian Lance Taylor wrote: On Fri, May 22, 2015 at 3:11 PM, Andrew Chambers andrewchambe...@gmail.com wrote: I'm not suggesting breaking go conventions, I just think the default if no GOARCH is specified then it should match --target. Sounds good to me. Perhaps we

Re: [PATCH 3/4] split-stack for powerpc64

On 05/19/2015 07:52 PM, Alan Modra wrote: On Tue, May 19, 2015 at 07:40:15AM -0500, Lynn A. Boger wrote: Questions on the use of the options for split stack: - The way this is implemented, split stack is generated if the target platform supports split stack, on ppc64/ppc64le as well

Re: [PATCH 3/4] split-stack for powerpc64

that the app could fail and it won't be clear why. Maybe the gold linker isn't required to make it work for most cases, but it will fail for some cases without it. On 05/20/2015 07:58 AM, David Edelsohn wrote: On Wed, May 20, 2015 at 8:13 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: On 05/19/2015

Re: [gofrontend-dev] GO tools for gccgo cross

to get gccgo to work on cross. Is it too late to try and get this into gcc 5.0? I think it's still possible. Depends on how small and safe it is. Ian On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote: On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger lab

Re: libgo patch committed: Build libnetgo.a

, Ian Lance Taylor wrote: PR 63731 points out that when using gccgo there is no way to request a Go program that uses the native Go DNS lookup code rather than using the system libraries. This patch from Lynn Boger at least provides a mechanism for that, by adding a -lnetgo library that can be used

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

On 02/27/2015 02:46 PM, Ian Lance Taylor wrote: On Fri, Feb 27, 2015 at 12:07 PM, Matthias Klose d...@ubuntu.com wrote: is there anything which could be stripped without scarifying functionality? Linux distributions usually strip things by default, so a hint what exactly is needed to keep the

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

I removed the 3 debug sections from libgo that were listed on the objcopy command. I left in: debug_info, debug_line, debug_abbrev, debug_ranges, and debug_str in their original form. On 03/02/2015 01:58 PM, Ian Lance Taylor wrote: On Mon, Mar 2, 2015 at 11:50 AM, Lynn A. Boger labo

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

libgo sizes 32665042: original size 27607770: after removing the debug sections using the objcopy command from below 22474602: after removing all debug sections using objcopy On 03/02/2015 02:08 PM, Ian Lance Taylor wrote: On Mon, Mar 2, 2015 at 12:05 PM, Lynn A. Boger labo

Re: [gofrontend-dev] Re: Go patch committed: Don't strip Go programs

At a minimum I think it should be mentioned in libgo/README. I'll have to ask around to find out where would be best so that anyone who builds libgo for distribution knows that the debug info should not be stripped. I'm not sure about other places On 02/27/2015 09:59 AM, Ian Lance Taylor

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add support for missing reflection functions to gccgo for ppc64, ppc64le in gcc 4.9

) { case error: return t default: return nil } } On 02/06/2015 05:05 PM, Ian Lance Taylor wrote: On Fri, Feb 6, 2015 at 12:36 PM, Lynn A. Boger labo...@linux.vnet.ibm.com

GO tools for gccgo cross

Hi, I've been experimenting with the go tools and how to make them work for cross gccgo builds. In golang I think there is just one 'go' tool and the cross build targets are specified by the setting of GOARCH and GOOS. So why couldn't the same be done with gccgo? That means, on any given

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

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 labo...@linux.vnet.ibm.com wrote: I have an updated patch for the reflection functions in gcc 4.9

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

the decision changed concerning whether or not this patch might be accepted into the gcc 4.9 branch? If so, I will post the updated patch. On 01/08/2015 08:53 AM, Ian Lance Taylor wrote: On Thu, Jan 8, 2015 at 5:44 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: Also as was noted below

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

. On 01/07/2015 07:20 PM, Ian Lance Taylor wrote: On Wed, Jan 7, 2015 at 4:39 PM, Michael Hudson-Doyle michael.hud...@canonical.com wrote: Ian Lance Taylor i...@golang.org writes: On Wed, Jan 7, 2015 at 9:26 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: In libgo/go/reflect/makefunc.go, calls

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

to make it work. I hope that answers your question? I have not done a thorough testing/investigation of reflection in gccgo 4.9 on Power and my statement refers only on the above information. On 01/08/2015 08:53 AM, Ian Lance Taylor wrote: On Thu, Jan 8, 2015 at 5:44 AM, Lynn A. Boger labo

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

Taylor wrote: On Tue, Jan 6, 2015 at 7:37 AM, Lynn A. Boger labo...@linux.vnet.ibm.com 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

Re: [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

for these goarch values in a later submission. Thanks. On 01/06/2015 12:38 PM, Lynn A. Boger wrote: Sorry, hold off on this one for now. I missed the update to libgo/go/reflect/all_test.go for ppc64 and ppc64le in this patch and when changed to actually test these goarch values it is failing

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

be accepted the way it is. I will work on fixing that and then figure out what branch is best to include it in. On 01/07/2015 10:54 AM, Ian Lance Taylor wrote: On Wed, Jan 7, 2015 at 8:43 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: I thought that since this only affects ppc64 and ppc64le

[PATCH 0/2] Add reflection support for ppc64, ppc64le to gcc 4.9

Please add the following pair of patches to gcc 4.9. These two patches add reflection support for ppc64 ppc64le to gccgo in gcc 4.9, along with a fix for recover that is needed once the reflection support is in place. A bootstrap build and testing was done on ppc64 ppc64le. Changes

Re: [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

Sorry, hold off on this one for now. I missed the update to libgo/go/reflect/all_test.go for ppc64 and ppc64le in this patch and when changed to actually test these goarch values it is failing. On 01/06/2015 09:37 AM, Lynn A. Boger wrote: Add support for reflection for gccgo in gcc 4.9

[PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

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. 2015-01-06Lynn Boger labo...@linux.vnet.ibm.com * libgo/Makefile.am: Build the new files for libgo

[PATCH 2/2, libgo] Backport recover fix for gccgo to gcc 4.9

This is a backport to gcc 4.9 of the following change: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00660.html. The original patch had changes required for use with the FFI reflection support. Since FFI is not used for reflection in gcc 4.9 those changes were omitted. 2015-01-06Lynn

Re: [PATCH, libgo] Backport fix for compiler flags in mksysinfo.sh to gcc 4.9

This one should not be backported. It was submitted but not added upstream. Sorry for the confusion. On 12/30/2014 01:33 PM, Lynn A. Boger wrote: Hi, Please backport the change from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00713.html to gcc 4.9. 2014-12-30 Lynn Boger labo

[PATCH, libgo] Backport for PPC64 reloc fix to 4.9

Hi, The following should have been included with the backport for 4.9 in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01383.html to allow the debuginfo to be read for EM_PPC64. 2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com * libgo/go/debug/elf/file.go: Read debug_info for EM_PPC64

[PATCH, libgo] Backport for handling of 64 bit symbol tables in gccgo

Hi, Please backport the following fix to the gcc 4.9 branch. 2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com * gcc/go/gofrontend/import-archive.cc: Recognize 64-bit symbol tables Index: gcc/go/gofrontend/import-archive.cc

[PATCH, libgo] Backport to gcc 4.9 GOARCH setting for ppc64le

Hi, Please backport this change to the gcc 4.9 branch so that the GOARCH value setting for ppc64le is consistent with trunk. This has been bootstrapped and regression tested on ppc64le and ppc64 (along with the other patches submitted for the 4.9 branch today). 2014-12-30 Lynn Boger labo

[PATCH, libgo] Backport fix for compiler flags in mksysinfo.sh to gcc 4.9

Hi, Please backport the change from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00713.html to gcc 4.9. 2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com * libgo/mksysinfo.sh: Add the same compiler flags used by configure to detect whether off64_t is present when generating

[PATCH] backport libgo patch to add ioctl consts

Hi all, Please backport the following to gcc 4.9 https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02980.html. There has been a request to get the fixes that went into gcc trunk for gccgo ppc64 ppc64le backported into gcc 4.9. 2014-12-11 Lynn Boger labo...@linux.vnet.ibm.com * libgo

[PATCH] Set goarch to ppc64le where needed for gccgo testing

with the above change to gofrontend on ppc, ppc64, and ppc64le. 2014-11-19 Lynn Boger labo...@linux.vnet.ibm.com * gcc/testsuite/go.test/go-test.exp: Add case for ppc64le goarch value for go testing Index: gcc/testsuite/go.test/go-test.exp

Re: [PATCH] Set goarch to ppc64le where needed for gccgo testing

Sorry. I ran 'make check-go' assuming it ran both m32 and m64 on a ppc64 machine. I'll fix and retest. On 11/19/2014 10:08 AM, Segher Boessenkool wrote: On Wed, Nov 19, 2014 at 09:01:35AM -0600, Lynn A. Boger wrote: + powerpc-*-* { + set goarch ppc

Re: [PATCH] Set goarch to ppc64le where needed for gccgo testing

+ } } } s390-*-* { On 11/19/2014 09:01 AM, Lynn A. Boger wrote: Hi, This change goes along with the change to the GOARCH setting in gccgo for ppc64le which will be done in gofrontend. The description for that change is here: https://groups.google.com/forum/#!topic/gofrontend-dev

Re: [PATCH 00/13] Go closures, libffi, and the static chain

Aren't there cases where the static chain register is needed? How does that work if it could be trashed on a plt call? On 11/06/2014 06:48 AM, Alan Modra wrote: On Thu, Nov 06, 2014 at 07:59:16AM +0100, Richard Henderson wrote: I haven't done powerpc yet. If you'd like to help, I'd be

Re: [PATCH 00/13] Go closures, libffi, and the static chain

What about the libffi changes that are needed to make this work on other platforms, like PowerPC? On 10/10/2014 03:42 PM, Richard Henderson wrote: Pardon the wide distribution, the obvious hacks, and the failure to properly split up the largest of the libffi patches. The background here is my

Re: gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

I will start with the gccgo contribution process from golang. Thanks! Lynn On 10/15/2014 08:26 PM, Ian Lance Taylor wrote: On Wed, Oct 15, 2014 at 1:41 PM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: I'm working on a patch submission for gccgo to add the R_PPC64 relocation definitions

gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

Hi, I'm working on a patch submission for gccgo to add the R_PPC64 relocation definitions to libgo/go/debug/elf/elf.go. Along with this submission I was going to update the testcase file_test.go from the same directory so it would test the new defines for ppc64 relocation. This test

Re: [PATCH 1/9] Gccgo port to s390[x] -- part I

With this change along with PATCH 1/9, the recover.go testcase passes, there are no new regressions on for ppc64 LE or BE or ppc (32 bit BE) when running the go and libgo testsuites and I agree is the right solution. Thanks, Lynn On 09/25/2014 06:44 AM, Ulrich Weigand wrote: Lynn Boger wrote

Re: [PATCH 1/9] Gccgo port to s390[x] -- part I

[PATCH 1/9] Gccgo port to s390[x] is a fix for BZ 60406. When building with this patch on ppc64 LE, the failing testcase from the BZ is fixed and there are no new failures; however when building with this patch on ppc64 BE there are over 20 new failures in the go and libgo testsuites. I