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=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 bootstrapped
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
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 #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. Maybe
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: reflect
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
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
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
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
: 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
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=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?
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
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
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/gospec.c:161
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198
--- Comment #6 from boger at us dot ibm.com ---
I am working with our Docker team to provide a source change that will compile
with old and new gccgo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198
--- Comment #2 from boger at us dot ibm.com ---
I was asked to make this fix to gccgo. A corresponding Docker fix is needed
which is described here https://github.com/docker/libcontainer/pull/625.
It is unfortunate it introduces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198
--- Comment #4 from boger at us dot ibm.com ---
I'll admit I'm not familiar with how this field could ever be used.
But you are saying that no code will ever try to do a compare with this field
when has a value greater than 127? If it did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #21 from boger at us dot ibm.com ---
Created attachment 36142
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36142action=edit
Configure gold with split stack based on binutils version
This is an updated version of the previous
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=36132action=edit
Configure gold linker with split stack if available
Attaching my patch to detect for split stack
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 another ;;?
Can you
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 #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 on the 32 bit build
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 #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
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=35989action=edit
Clean up checks for flag_split_stack and attribute no_split_stack
Made the change related to Alan's
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)
@@ -295,6 +291,11
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 work
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.org
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
--- a/gcc/go/go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574
boger at us dot ibm.com changed:
What|Removed |Added
Severity|critical|normal
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|normal |critical
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=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?
gdb go
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
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=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.
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 sure
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=35344action=edit
Increment the pc in the callback routine for backtrace_full
Always increment the pc in the callback
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-callers.c
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=35347action=edit
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=65772
--- Comment #1 from boger at us dot ibm.com ---
Created attachment 35321
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35321action=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
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
: 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
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=35260action=edit
libgo/go/go/build/doc.go documentation update
Adding comments about the use of the netgo tag
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 #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
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=35195action=edit
Fallback netgo solution for gccgo
This patch updates the libgo Makefile to build and install
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=65462
--- Comment #1 from boger at us dot ibm.com ---
Created attachment 35077
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35077action=edit
Fix dependencies in go tool for gccgo
The code to determine when to import packages was not quite
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 #2 from boger at us dot ibm.com ---
Created attachment 35081
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35081action=edit
Updated patch to add unsafe to the list of std package names
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 build the dependent packages
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=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 results
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
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. Maybe we should
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 which
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
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=34995action=edit
Proposed fix
Here is my proposed fix to correct the problem on Power, and mostly fix it for
s390/s390x
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 the pc
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_xadd
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 #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. That seems prone to error
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 code
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 it fixed
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 constructor attribute
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=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 called
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=64876
boger at us dot ibm.com changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
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=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 package which
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
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://golang.org/cmd/go for documentation
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 #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 situation you
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 gc the net
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 #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 #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=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=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=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 least
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=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
1 - 100 of 104 matches
Mail list logo
