Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Docker uses a call of the exec family to start a new process with a bogus
argv[0] argument, i.e. argv[0] points to an empty file, not a real executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61895
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
execv(argv[0], argv[1]);
^^^ ^^^
1 2
Sorry.
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
There's an array bounds overrun in
gfortran/generated/bessel_r4.c:bessel_yn_r4(). The function is passed the
arguments n1 and n2 (n1 = n2) and allocates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188
--- Comment #3 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
(In reply to kargl from comment #1)
I assume you found this by using a libc with
a malloc that has buffer overflow detection.
Actually, no. We inspected the function manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #6 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I'll submit a fix for this problem as soon as I figure out what to do with the
patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 33468
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33468action=edit
Test prog for Go
Run and watch for differences in the output lines. They should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
--- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 33469
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33469action=edit
Test prog for C
Run with ./mycplx2_c 5 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
--- Comment #3 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
So the problem is that for some targets gcc's constant folding may yield a
different result for floating point calculations than the result if the
calculations were done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
On s390x, the option -fcx-limited-range fixes the deviation in the C test
program (tried with -O0 and -O3), but it has no effect for the Go test program.
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
There are several flaws in the math library test code. On s390x, the test
TestLog2 fails for three reasons:
1) This part of the test is too strict for i == 0:
for i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 33493
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33493action=edit
Proposed fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 33506
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33506action=edit
updated patch
Managed to get a stray character into the test between testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #14 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with --enable-sjlj-exceptions;
Why is that important?
2) the current code almost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #17 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
* Wouldn't the new patch re-introduce the bug that
func foo(n int) {
if (n == 0) { recover(); } else { foo(0); }
}
func main() {
defer foo(1)
panic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #22 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Hm, so the patch penalises platforms that cannot deal with the
16 byte window?
Yes, but, recall that on your system almost all tests pass using the
code that is in the tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #23 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Regarding the new patch:
1) We need to call __builtin_extract_return_address(retaddr) in
__go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
the most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #24 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
--snip--
-g-defer-__retaddr = retaddr;
+g-defer-__retaddr = __builtin_extract_return_addr (retaddr);
--snip--
We need to double check whether this would break Sparc.
: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
(using git commit id e63988cca99cbbf6e5c459379309fe3359fe7c09)
The test case convert.go fails with a panic in a panic on System/z:
-- snip --
fatal error: markspan: unaligned pointer
goroutine 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
On Wed, Feb 12, 2014 at 12:34:06AM +, ian at airs dot com wrote:
I suspect this problem was fixed by revision 205940 in the GCC Subversion
repository, committed 2013-12-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
Created attachment 32179
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32179action=edit
test program
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207936
138bc75d-0d04-0410-961f-82ee72b054a4
This program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
So it looks like gccgo reads the expression as
(*pg)(0)
I meant
- (*(g))(0)
while golang reads it as
*(pg(0))
- *((g(0)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
On s390, if a type with __attribute__((aligned(...))) is passed as a function
parameter, the parameters are not aligned properly. Also, a parameter that is
passed in a register and then copied
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 32209
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32209action=edit
test program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
(libffi does not honour the alignment either.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
It's the same on x86 I suppose
Well, the test program works fine on my amd64 box i.e. the alignment is
correct in all three functions (I guess foo() needs more int args to force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
With -O2 and -O3 all three cases generate the proper alignment
With -O1 only foo() has the proper alignment
With -O0 none of the cases has the proper alignment
== Code compiled
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
From a email discussion between me (DV) and Ian Lance Taylor (IT):
DV: The bug shows up when running recover.go from the go testsuite
DV: in the function test13reflect2 (and test14reflect2).
DV:
DV: When panic
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
From an email discussion between me and with Ian Lance Taylor about the
function statements.cc:build_thunk():
Ian Lance Taylor wrote:
On Fri, Mar 28, 2014 at 3:37 AM, Dominik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60728
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
See Also||http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #29 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Thanks!
It's necessary to handle all cases correctly. But there is nothing wrong
with using an efficient mechanism when it works, as long as we can correctly
fall back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
regarding 2)
I'm not entirely persuaded by your argument for item 2. ...
Hm, good that you doubted it, because the actual mistake is somehwere else:
The unpatched code has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
regarding 1)
My earlier explanation of the problem was wrong. Multiply and add is not
generated; it probably only was in the artificial test case that I made and
certainly did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #6 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
(In reply to Ian Lance Taylor from comment #3)
First, let me say that this code is in the Go master library and must be
fixed there. It might be more effective to discuss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #10 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
This still happens for me on s390x on git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/trunk@217069
138bc75d-0d04-0410-961f-82ee72b054a4. Is this supposed to be fixed by now?
Is one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #11 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
With the two patches for calls.c and expr.c atop the said commit the ICE is
gone on s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #21 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
With today's HEAD, the ICE in libgo is gone (s390x). Thanks.
at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
This test program genererates an ICE with the current gccgo HEAD:
-- snip --
package main
func main() {
var x int = 0
println(x++)
}
-- snip --
==
$ gccgo foo.go
foo.go:4:18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Just noticed that all function offsets in the stack traces are broken. On
s390x, only even offsets are valid, but all the numbers are odd, e.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
These entries looks screwed to me:
-- snip --
32: 1024 [32: 1024] @ ...
#0x8000c44b ...allocatePersistent1K ... mprof_test.go:43
#0x8000c595 ...TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
The stack traces in gdb look good:
line 64:
#0 __go_new (td=td@entry=0x8010c8e8 __go_td_S1_xAN5_uint81024ee,
size=size@entry=1024) at ../../../libgo/runtime/go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #20 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
runtime_MProf_Malloc() calls runtime_callers() without going through
runtime.Callers():
#0 runtime_callers (skip=skip@entry=1, locbuf=locbuf@entry=0xc2094734b8,
m=m@entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #10 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
As far as I understand, the code in libbacktrace was originally only intended
for handling exceptions, not for generating stack traces? For the former, the
code is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #18 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 34788
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34788action=edit
Different fix
How about this patch to the callback() function in go-callers.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #22 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
You mean the function saveg() code in mprof.goc?
I'm actually not sure how the above patch to runtime_callers() interacts with
all the other functions that call runtime_callers(). :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #17 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
runtime.Callers is not called in this test case, so changing it won't help.
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
With the current trunk I get a test failure in the runtime/pprof test. I'll
start investigating what's going on now but wanted to report it beforehand.
Any hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #7 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
The --pc is definitely the cause of the bogus addresses. To me it seems that
these addresses are intended to identify the function and source line from the
dwarf info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #8 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
The cause for this bug is the interaction between the --pc and this code
snippet from printStackRecord() in pprof.go:
... if runtime.GOARCH == s390 || runtime.GOARCH == s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #13 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I see.
But what bug or bugs do we have here then? Current symptoms are:
(1) A bogus call addres may be stored in the backtrace structure (i.e. next
instruction's address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #14 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 34773
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34773action=edit
Experimental fix
The attached patch is a sketch of a possible fix (at the expense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #15 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
P.S.: The patch only addresses s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #35 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I'd like to bring back to attention the fact that the code that deducts six
from the pc (s390x) in pprof.go is broken regardless of what patches are made
to the runtime code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
CC||vogt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #29 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
(In reply to Ian Lance Taylor from comment #27)
The problem is that we can't represent full file/line
information using a single PC value, because a single PC value can't
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
With current code from gcc_5_branch, the Go test bug347.go crashes by
dereferencing a null pointer:
-- snip --
$ gdb ./bug347.x
(gdb) run
Starting program: /home/vogt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #60 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Works on s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Wouldn't the correct and easy to identify place be right after the first
NOTE_INSN_BASIC_BLOCK?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
CC||vogt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #6 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Ah, forget it, the addresses are okay; I'll dig deeper into the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Funny, the backtrace claims that 0x80001de7 ist main.main+23 (#0 of the
backtrace), but it actually is main.main-1 (#7).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #9 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
The problem is reproduceable with the makecontext C testcases in Glibc (with
some manual intervention). So, this isn't a Go related problem. Our analysis
so far seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #10 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Just a short update before the bank holiday weekend in Germany. The problem is
caused by missing cfi directives in the Glibc sources. We'll open a Glibc bug
report and provide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #24 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Okay, I've made a new patch that fixes the problem with only the hotpatch tests
running in the s390 test suite. This change passes all tests on 64 and 31 bit.
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #26 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
The patch for upstream gcc is available here:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02739.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #29 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
As this still seems to work in 4.8, 4.9 and 5.1, is it acceptable to only fix
this on the master?
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
This small test program derived from gcc.dg/inline-39.c (by adding the inline
keyword) exposes an ICE on s390x, but this may be/probably is a problem on all
platforms:
-- snip --
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #7 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
When dumping the complete backtrace, gdb produces a warning. Maybe the
libgo/runtime code does not properly set up the initial stack frame of the
thread?
(gdb) set backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #7 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 35595
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35595action=edit
Experimental fix
Can you please check whether this patch works for you? The patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #20 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
I'll remove -O0 from the list of torture test options so that the list of
hotpatch torture tests is only defined in one place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Attachment #35599|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #11 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
(In reply to Jakub Jelinek from comment #10)
As for the hotpatch testcases, have you tested them also with
-fno-dwarf2-cfi-asm (as they seem to contain .cfi directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #9 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Yeah, I accidentally left the other test cases commented out. I'll clean that
up in the next version of the patch. That doesn't have an impact on the
correctness of the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #12 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 35597
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35597action=edit
Experimental fix 2
Version 2 of the patch with the suggested changes and test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #14 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Is it possible that a function has no insns at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Attachment #35597|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Attachment #35598|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #3 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Sorry, the expample with t2() in the code snippet above should have the pragmas
in the opposite order:
-- snip --
#pragma GCC target (no-sse)
#pragma GCC target (fpmath=sse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 36136
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36136action=edit
warning
Code that produces the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66363
Dominik Vogt vogt at linux dot vnet.ibm.com changed:
What|Removed |Added
Component|target |ipa
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
There's a bug in the way the GCC target pragma is translated into the
target attribute on x86, and probably also on (all?) other platforms that
base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 36135
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36135action=edit
no warning
Code that does not produce the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #13 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Can this be closed? It's not a Gcc bug but a Glibc problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Created attachment 36139
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36139action=edit
experimental fix
The attached patch fixes the problem for me (on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Also, it is a bad idea to pass global_options_set in this call
ix86_valid_target_attribute_tree (args, global_options,
global_options_set);
because it may be modified (via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #5 from Dominik Vogt ---
Unfortunately I cannot reproduce this yet. Please try to identify the "faulty"
source file and strip it down to the minimum.
1. Find out in which file the ICE occurs.
1.a Recompile GCC with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #6 from Dominik Vogt ---
@Ian: Any hints to help Gong isolating the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #21 from Dominik Vogt ---
Trying to write a test case for Power, I was unable to force the bug to show in
the first place. Although I can force the addresses used into different
registers, dead store elimination on power does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976
--- Comment #1 from Dominik Vogt ---
When cgo encounters the "C.foo_cgo", it determines that it must be a variable,
but finds no C definition, so it generates "extern char foo_cgo[]" (out.go) as
the type. This conflicts with the declaration in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #8 from Dominik Vogt ---
I had been testing with the latest gcc-5-branch and didn't see any ICEs but a
lot of other problems with the ethereum package that may be the fault of the
code or cgo, I don't know. I can see the ICE on
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
Target Milestone: ---
Host: s390x
Target: s390x
Build: s390x
Compiling the package crypto/secp256k1 from the go-ethereum package yields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #3 from Dominik Vogt ---
To narrow down where the problem happens please try this:
1. Edit the first line of the file build/env.sh and append "-a":
#!/bin/sh -a
2. Locate the gccgo executable (whould be in the path GOBIN that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #11 from Dominik Vogt ---
Created attachment 36596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36596=edit
Minimal test code
The attached test code causes the ICE on s390x and x86_64 using gccgo-5.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976
--- Comment #3 from Dominik Vogt ---
When do you expect Go 1.5 to be merged?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976
--- Comment #4 from Dominik Vogt ---
The patch behind the link in comment 2 fixes the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #12 from Dominik Vogt ---
The test code also crashes on x86_64 with the current gcc-5-branch and the
gcc-6 development branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
--- Comment #10 from Dominik Vogt ---
We cannot reproduce the crash on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #3 from Dominik Vogt ---
Created attachment 36588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36588=edit
Experimental fix
The attached patch fixes the problem for us by skipping DW_TAG_variable DWARF
info that only contains
1 - 100 of 464 matches
Mail list logo
