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.
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 t
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 agains
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 at
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
* common.opt (-ftrampolines): New option.
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
wrote:
The libgo tests on ppc64le and ppc64 have all been failing in
gcc-testres
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
wrote:
The libgo tests on ppc64le and ppc64 have all been failing in
gcc-testresults since this change went in and continues to fail
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 single
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
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. I'v
ppc64
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
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 64 bit. The failures
do not occ
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
`/home/boger/g
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
wrote:
I see this error when bui
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(&fpgrp)))
To make it easier to use gotools go and gofmt, add -static-libgo when
linking them. This makes it nicer
in all cases since it eliminates the dependency on libgo.so for these
tools, but it is mostly helpful for
the cross compiled case. When building for use in the cross compiled
case, this allo
, Andreas Schwab wrote:
"Lynn A. Boger" writes:
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h (revision 228653)
+++ gcc/config/rs6000/sysv4.h (working copy)
@@ -940,13 +940,15 @@ ncrtn.o%s
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" writes:
:
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
7:36, Lynn A. Boger wrote:
Pretty sure this is the fix, but still doing some testing.
linux.h isn't included for multilib enabled builds defaulting to
powerpc-linux-gnu, I am currently testing
--- gcc/config/rs6000/sysv4.h(revision 228571)
+++ gcc/config/rs6000/sysv4.h(working
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
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 tested on ppc64le, ppc64 multilib
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined
go/gospec.c: (lang_specific_driver): Set appropriate
split stack
options for 64 bit compiles based on
TARGET_CAN_SPLIT_STACK_64BIT
On 09/15/2015 02:58 PM, Ian Lance Taylor wrote:
On Tue, Sep 15, 2015 at 11:24 AM, Lynn A. Boger
wrote:
I
David Edelsohn wrote:
On Thu, Aug 27, 2015 at 5:00 PM, Lynn A. Boger
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 linker, but that is not necessary since in that
c_driver): Use
TARGET_CAN_SPLIT_STACK_64BIT
to control setting of fsplit-stack and u,pthread_create
options for 64 bit
compiles.
On 08/19/2015 06:05 PM, Lynn A. Boger wrote:
Also, I don't think it is sufficient to add the option to enable the
gold linker in gospec.c. T
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* |
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
wrote:
libgo/
PR target/66870
configure.ac: When gccgo for
added 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 en
nt 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 o
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 of the gold linker with the split stack option results in less storage
allocated for goroutine stacks; if split stack is used without the gold
lin
The attached patch fixes a problem identified in PR66870 with
split stack on ppc64 and ppc64le. If flag_split_stack is true, but
the function being processed has the no_split_stack attribute, then
the split stack prologue should not be generated.
Bootstrapped on ppc64le-linux and ppc64-linux, pa
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 +
I have tested this and it fixes the problem.
On 07/01/2015 09:15 AM, Andreas Schwab wrote:
"Lynn A. Boger" 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.
The failur
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, Andre
On 05/22/2015 05:50 PM, Ian Lance Taylor wrote:
On Fri, May 22, 2015 at 3:11 PM, Andrew Chambers
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 could check the symlink name f
t 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
wrote:
On 05/19/2015 07:52
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
as 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
wrote:
I've been experimenting w
I see there is some documentation about build constraints in
go/go/build/doc.go.
There is no mention of netgo on this page now but this seems like an
appropriate
spot to mention the use of the netgo tag for gc and then how to achieve the
equivalent effect with gccgo.
On 04/07/2015 01:09 PM, Ian
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
wrote:
I
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
wrote
On 02/27/2015 02:46 PM, Ian Lance Taylor wrote:
On Fri, Feb 27, 2015 at 12:07 PM, Matthias Klose 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 functionality wo
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 wrot
ce().(type) {
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
wrote:
I w
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
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 al
on this patch, has 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
wrote:
Also as was noted below, some level
ion and it wasn't there
and this patch was used 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:
O
out. Thanks.
On 01/07/2015 07:20 PM, Ian Lance Taylor wrote:
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 w
;t 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
wrote:
I thought that since this only affects ppc64 and ppc64le, and provides
refle
Lance Taylor wrote:
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 thi
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
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. This
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 Bog
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
* libgo/Makefile.am: Build the new files for libgo reflection
support on ppc64, ppc6
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 inc
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
* libgo
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
* libgo/mksysinfo.sh: Add the same compiler flags used by
configure to detect whether off64_t is present
when generating the go structures for C types.
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
*
Hi,
Please backport the following fix to the gcc 4.9 branch.
2014-12-30 Lynn Boger
* gcc/go/gofrontend/import-archive.cc: Recognize 64-bit symbol tables
Index: gcc/go/gofrontend/import-archive.cc
===
--- gcc/go/gofrontend/
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
* libgo/go/debug/elf/file.go: Read debug_info for EM_PPC64
Index: libgo/go/debug/elf/fi
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
* libgo/mksysinfo.sh: Add ioctl const
{
+ set goarch "ppc64"
+ }
}
}
"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
t
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-*-*" {
+
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/ocEttrpsw-s
This change has been bootstrapped and tested along with the abo
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 deligh
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
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
wrote:
I'm working on a patch submission for gccgo to add the R_PPC64 relocation
definitions to libgo/go/debug/elf/e
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 current
Hi,
I removed my change to statements.cc and made a change as you suggested
in libgo/runtime/go-defer.c in function __go_set_defering_fn:
+#if defined(__powerpc64__) && _CALL_ELF != 2
+g->defer->__defering_fn = *(void **)defering_fn;
+#else
+g->defer->__defering_fn = defering_fn;
+#end
[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 modif
69 matches
Mail list logo
