https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #8 from boger at us dot ibm.com ---
An update was made to go1.10beta2, so I rebuilt with the updates but the same
error happens at the same statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #21 from boger at us dot ibm.com ---
(In reply to Alexandre Oliva from comment #19)
> I was copied, presumably because the problem occurred in var-tracking.
>
> I've tried to duplicate the problem on gcc112. I bootstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #25 from boger at us dot ibm.com ---
A few other variations that enable it to work even with a power8 configuration:
Compiling with -fdisable-ipa-cp prevents the ICE.
OR
Using the //go:nosplit directive before the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
--- Comment #11 from boger at us dot ibm.com ---
The first failure happens in TestParseIP from ip_test.go because the "out"
entries in the var parseIPTests are not initialized correctly. This causes the
failures because the actual va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
--- Comment #14 from boger at us dot ibm.com ---
I have found the incorrect code that is causing this test to fail but not sure
what causes it. My previous theory was not correct.
The problem is that the second argument being passed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
--- Comment #16 from boger at us dot ibm.com ---
After further investigation I found the original testcase failures started
happening with an earlier commit, which I have verified as 247497. That commit
caused 7 new libgo testcase failures, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
--- Comment #17 from boger at us dot ibm.com ---
Here's more info on the failures and how to reproduce them. Starting with
commit 247497 there are 7 new failures in the libgo testsuite.
There are 4 that fail with a SEGV at runtime: re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
--- Comment #19 from boger at us dot ibm.com ---
Is someone building and testing gccgo on x86_64 on a regular basis? If I look
at the gcc-testresults output for x86_64 I don't see the go or libgo test
results like I do for ppc64le. May
: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target Milestone: ---
There are 3 failures in the gccgo testcases starting with commit 241222. I
built with 241215 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #42 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #41)
> I really don't want libbacktrace to be processor-dependent. That makes all
> uses of it more complex for no significant gain. Mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #44 from boger at us dot ibm.com ---
If we do the increment of the pc to fix it in the callback, here is how that
happens:
- backtrace_full gets the pc and decrements by 1
- backtrace_full calls backtrace_pcinfo to look up the file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #48 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #47)
> We have to separate backtrace_full and backtrace_simple, which are part of
> the libbacktrace library, from functions like runtime_callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #50 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #49)
> libbacktrace returns the line number that you actually care about: the line
> number of the call instruction. There is no question that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #46 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #45)
> If we change the PC returned by backtrace_full, and then use that changed PC
> to look up file/line information, we might get different r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #51 from boger at us dot ibm.com ---
Here is the change I made to go-callers.c. This patch along with my previous
changes to extern.go and pprof.go allows the test identified in this issue to
report the correct line number on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #53 from boger at us dot ibm.com ---
I was taking the approach of only fixing what was known to be broken, and I was
not aware that this was broken on other platforms. Minimizing risk. I can
change it for all platforms but these
ty: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
When using the go tool provided with gccgo in gcc 5.0, the use of 'go get'
doesn't always find and bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #31 from boger at us dot ibm.com ---
Here are two suggestions to solve this issue without having to use the -a and
-tags netgo options to rebuild packages at build time. Since this is a common
problem, it seems best to provide a way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65462
--- Comment #1 from boger at us dot ibm.com ---
Created attachment 35077
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35077&action=edit
Fix dependencies in go tool for gccgo
The code to determine when to import packages was no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65462
--- Comment #2 from boger at us dot ibm.com ---
Created attachment 35081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35081&action=edit
Updated patch to add unsafe to the list of std package names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65462
--- Comment #4 from boger at us dot ibm.com ---
Do you mean as if submitting to gofrontend-dev?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65462
--- Comment #6 from boger at us dot ibm.com ---
I decided that you meant the gofrontend so here it is (just did the hg mail)
https://codereview.appspot.com/213570043/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #32 from boger at us dot ibm.com ---
I have a prototype working for #2. I am assuming #1 would not be accepted.
This fix consists of building a library called libnetgo.a which consists of the
net files that would be built if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #33 from boger at us dot ibm.com ---
Created attachment 35195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35195&action=edit
"Fallback" netgo solution for gccgo
This patch updates the libgo Makefile to buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #34 from boger at us dot ibm.com ---
Created a codereview: https://codereview.appspot.com/217620043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #37 from boger at us dot ibm.com ---
Created attachment 35260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35260&action=edit
libgo/go/go/build/doc.go documentation update
Adding comments about the use of the netgo tag
: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: ppc64le, ppc64, x86_64
packer testcase fails due to incorrect reflected struct field when test is
built with gccgo. Failure occurs with gccgo on
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: ppc64le, x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65772
--- Comment #1 from boger at us dot ibm.com ---
Created attachment 35321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35321&action=edit
testcase for bad return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65772
--- Comment #2 from boger at us dot ibm.com ---
When running the attached testcase on a platform with gccgo (ppc64le, x86_64),
the test fails due to incorrect return values from the function getList. The
source line for the return looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #55 from boger at us dot ibm.com ---
Created attachment 35344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35344&action=edit
Increment the pc in the callback routine for backtrace_full
Always increment the pc in the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #56 from boger at us dot ibm.com ---
Here is a bit more detail. Now that I think I understand all the
considerations, I'm proposing this simple fix for gcc 5. Maybe longer term a
more thorough solution could be done but not su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180
--- Comment #2 from boger at us dot ibm.com ---
We've been putting most of the discussion on this in the bugzilla mentioned in
the previous comment.
However there is a simple fix for Power which I will add here:
ndex: libgo/runtime/go-call
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: ppc64le, x86_64, s390x
Created attachment 35347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35347&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
--- Comment #12 from boger at us dot ibm.com ---
Sorry I did not intend to reopen a closed bugzilla, I must not have looked
carefully enough and thought it was still open. Just wanted to document what I
found since their log output was the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180
--- Comment #6 from boger at us dot ibm.com ---
I have verified this testcase now passes on ppc64le with today's gcc-5-branch
and with gcc trunk.
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target Milestone: ---
Host: ppc64le, ppc64, x86_64
Target: ppc64le, ppc64, x86_64
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #25 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #24)
> ../../gcc/go/gospec.c: In function 'void
> lang_specific_driver(cl_decoded_option**, unsigned int*, int*)':
> ../../gcc/go/go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #28 from boger at us dot ibm.com ---
I could put back the #ifdef TARGET_CAN_SPLIT_STACK_64BIT around the OPT_m32
case if that is OK.
Doesn't fail on the builds for ppc64le or ppc64 either.
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target Milestone: ---
Escape analysis for Go was added to gcc trunk, but there are errors when using
it. It is not enabled by default, but requires the option -fgo-optimize-allocs
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68420
boger at us dot ibm.com changed:
What|Removed |Added
Target||ppc64le, x86_64
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574
--- Comment #6 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #5)
> Fixed on mainline.
Can this be backported to the gcc 5 branch?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: powerpc64
Many new failures appear in gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
boger at us dot ibm.com changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
--- Comment #8 from boger at us dot ibm.com ---
Yes, I can see that these regressions have gone away in the latest gcc
testresults on ppc64.
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: bergner at gcc dot gnu.org, cmang at google dot com
Target: ppc64le, ppc64
A regression appeared in the nightly gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #5 from boger at us dot ibm.com ---
(In reply to Tatsushi Inagaki from comment #0)
> Created attachment 34813 [details]
> Example to reproduce the constructor problem
>
> Gccgo ignores a C-function with the "construc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #26 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #25)
> To which code in libgcc are you referring? I don't see it.
>
Here is the code I was referring to, but I was wrong when I thought i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #28 from boger at us dot ibm.com ---
I'm not concerned about the inline case. The user could build without inlining
if it was important.
To me it seems like you don't want libbacktrace to decrement the pc when it is
being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #30 from boger at us dot ibm.com ---
I don't think it is a good idea to add code in multiple places to fix up the pc
values after calling runtime.Callers. That seems prone to error and confusing
for future updates to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #33 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #32)
> > I don't think it is a good idea to add code in multiple places to fix up
> > the pc values after calling runtime.Callers. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #29 from boger at us dot ibm.com ---
Yohei noted in comment 20 that this is also broken with gc in 1.4 when using
static linking. That was a while ago -- is that no longer a problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #36 from boger at us dot ibm.com ---
I'd like to take a step back and clarify what the functions in question,
runtime_callers, runtime.Caller, and runtime.Callers should be returning: the
pc values for the call instruction, or t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #38 from boger at us dot ibm.com ---
I've spent some time thinking about a fix for this and made a few other
observations...
I've noticed that when runtime_callers calls backtrace_full, it locks the
thread using runtime_xad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #40 from boger at us dot ibm.com ---
Created attachment 34995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34995&action=edit
Proposed fix
Here is my proposed fix to correct the problem on Power, and mostly fix it f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #6 from boger at us dot ibm.com ---
I understand why some functions like getaddrinfo don't work with static linking
unless the LD_LIBRARY_PATH is set to find libc.so, but then what should happen
if it isn't?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #9 from boger at us dot ibm.com ---
My question was: what is supposed to happen on fallback? Sounds like some
code gets rebuilt and used instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #11 from boger at us dot ibm.com ---
What I was asking is: what does it mean to call the pure-Go goLookupIP?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #13 from boger at us dot ibm.com ---
Then my question is: why isn't this "fallback" code always built for GO and
available to run instead of waiting until it hits this situation and then built
and run? In the si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #15 from boger at us dot ibm.com ---
I think what Ian is saying is that mechanism to rebuild packages in this way
doesn't work with gccgo (and probably never should?)
Now I'm finally understanding this. Originally with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #17 from boger at us dot ibm.com ---
Can you clarify how using -a -tags netgo actually works. I know it requires
that the source be available, but it must mean that it rebuilds the package for
the current link only, throws it away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #19 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #18)
> The -a option to "go build" means to rebuild all packages rather than using
> the installed versions (see http://golan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #21 from boger at us dot ibm.com ---
I'm confused by the description of -a in the go1.4 documentation.
I asked about this before and the answer was that each invocation of 'go build'
would create a copy of the built pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #23 from boger at us dot ibm.com ---
If I look at this documentation: http://tip.golang.org/doc/go1.4#gocmd
It says this:
The behavior of the go build subcommand's -a flag has been changed for
non-development installations
NCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
gccgo was built from trunk on power8 machines for both ppc64 and ppc64le with
the same result
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: bergner at vnet dot ibm.com, cmang at google dot com
Built gccgo from trunk.
Testcase cplx2.go in the go testsuite fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #7 from boger at us dot ibm.com ---
I've built with Dominik's patches against trunk on ppc64le and have been trying
to run the gcc testsuite for go and libgo.
The recover.go testcase continues to fail in my build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #8 from boger at us dot ibm.com ---
Update on my previous work:
1) My previous update referred to a build that was done with the patches that
were submitted to gcc and patches that Dominik provided me for libffi. I found
that if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #9 from boger at us dot ibm.com ---
The patch to fix the recover.go problem causes significant regression in gccgo
when built for ppc64 (BE). There are 32 unexpected failures in the gcc go
testsuite with the patch 32 unexpected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #11 from boger at us dot ibm.com ---
On ppc64 BE, the call to make_code_func_reference returns the function pointer
in the .opd and not the actual address of the function. That is what causes
the failures with this patch
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
boger at us dot ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
boger at us dot ibm.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
--- Comment #6 from boger at us dot ibm.com ---
If the last comment is true, does that mean the fold_const.c file in gcc should
be built in a way so that it doesn't use the fma, like using some kind of
option during the build of gcc at leas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #15 from boger at us dot ibm.com ---
The testcase recover.go continues to fail on both ppc64 LE & BE with the new
patch https://codereview.appspot.com/153950043.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #20 from boger at us dot ibm.com ---
The latest patch worked on ppc64 for LE & BE. That is, the testcase recover.go
now works and no new regressions were introduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198
--- Comment #8 from boger at us dot ibm.com ---
This fix is already in the gcc 5 branch commit r226595.
It was tracked in the golang issues database
https://github.com/golang/go/issues/11469.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368
--- Comment #6 from boger at us dot ibm.com ---
I think you've said the problem only occurs when using -fstack-protector-strong
and when building with glibc-2.21.
Have you tried using gdb to see where the segv actually occurs?
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66138
--- Comment #1 from boger at us dot ibm.com ---
I am not sure, but this appears to be similar to the golang issue I opened
yesterday https://github.com/golang/go/issues/11236 which was closed as a
duplicate of https://github.com/golang/go/issues
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target Milestone: ---
Target: ppc64le, ppc64, x86_64
Created attachment 35794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574
--- Comment #2 from boger at us dot ibm.com ---
I was asked to do that by my team leader in order to track these changes. If
you prefer it not be done that way I prefer that too and won't in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574
boger at us dot ibm.com changed:
What|Removed |Added
Severity|normal |critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66138
boger at us dot ibm.com changed:
What|Removed |Added
Severity|normal |critical
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574
boger at us dot ibm.com changed:
What|Removed |Added
Severity|critical|normal
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: amodra at gmail dot com, cmang at google dot com,
sch...@linux-m68k.org
Target Milestone: ---
Target: ppc64le, ppc64
Created attachment 35977
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #2 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #1)
> The various issues in this bug are in different parts of the code base. The
> bug is assigned to me, but, to be clear, I have no plans to w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #5 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #4)
> > past a few statements
>
> Huh??
Here is your patch
diff --git a/gcc/go/go-lang.c b/gcc/go/go-lang.c
index ce4dd9b..d952e0f 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #8 from boger at us dot ibm.com ---
Created attachment 35989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35989&action=edit
Clean up checks for flag_split_stack and attribute no_split_stack
Made the change related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #9 from boger at us dot ibm.com ---
(In reply to Andreas Schwab from comment #6)
> > (past a few statements)
>
> Huh?
>
> @@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options
> *opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #10 from boger at us dot ibm.com ---
Now that I am building on ppc64 with a new enough glibc, using my latest
patches for rs6000.c and Andreas' patch, and forcing the gold linker to be
used, I am hitting a testcase failure i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #13 from boger at us dot ibm.com ---
Use of the gold linker on ppc64 (BE) with static linking results in these
warnings:
/usr/local/gold/bin/ld.gold: warning:
/usr/lib/gcc/ppc64-redhat-linux/4.8.3/../../../../lib64/libc.a(malloc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #14 from boger at us dot ibm.com ---
I did bootstrap a build on ppc64 multilib, using Alan's latest and my patch and
Andreas' patch on a system with glibc >= 2.18. (Without Andreas' patch it
won't bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #15 from boger at us dot ibm.com ---
I have submitted my patch to gcc-patches to check for the no_split_stack
attribute after revising it based on Alan's comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #17 from boger at us dot ibm.com ---
Created attachment 36132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36132&action=edit
Configure gold linker with split stack if available
Attaching my patch to detect for spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #19 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #18)
> In the patch in comment #17, the code in gcc/configure.ac looks misplaced:
> shouldn't it be before the ";;", and not add a
1 - 100 of 104 matches
Mail list logo
