https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #5 from Dominik Vogt ---
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=66215
--- Comment #7 from Dominik Vogt ---
Created attachment 35595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35595&action=edit
Experimental fix
Can you please check whether this patch works for you? The patch also contains
improved test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #9 from Dominik Vogt ---
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 change, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #11 from Dominik Vogt ---
(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 in the regexps)?
Not yet. I'll add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #12 from Dominik Vogt ---
Created attachment 35597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35597&action=edit
Experimental fix 2
Version 2 of the patch with the suggested changes and test fixes.
Note: Functions without a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #14 from Dominik Vogt ---
Is it possible that a function has no insns at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Dominik Vogt changed:
What|Removed |Added
Attachment #35597|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Dominik Vogt changed:
What|Removed |Added
Attachment #35598|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #20 from Dominik Vogt ---
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 changed:
What|Removed |Added
Attachment #35599|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #24 from Dominik Vogt ---
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 this change we have done some cleanup wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #26 from Dominik Vogt ---
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 ---
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
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303
--- Comment #5 from Dominik Vogt ---
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 #6 from Dominik Vogt ---
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 #7 from Dominik Vogt ---
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 past-main
(gdb) bt
#0 main.main
Component: 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
g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134
--- Comment #4 from Dominik Vogt ---
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/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134
Dominik Vogt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Dominik Vogt -
ponent: go
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=32179&action=edit
test program
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207936
138bc75d-0d04-0410-961f-82ee72b05
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #1 from Dominik Vogt ---
> 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 changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Dominik Vogt -
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 to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #1 from Dominik Vogt ---
Created attachment 32209
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32209&action=edit
test program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #2 from Dominik Vogt ---
(libffi does not honour the alignment either.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #4 from Dominik Vogt ---
> 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
"a" onto the stack), and from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60337
--- Comment #5 from Dominik Vogt ---
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 with -O0 and -O3 accidentally u
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #28 from Dominik Vogt ---
Created attachment 36371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36371&action=edit
Outpout of the reload pass (BAD)
The full output of the reload pass on S/390, showing the behaviour described i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #29 from Dominik Vogt ---
I think I understand what's going on:
Consider the patched code in match_reloads():
+ = (ins[1] < 0 && REG_P (in_rtx)
+ && (int) REGNO (in_rtx) < lra_new_regno_start
+ && find_regno_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #32 from Dominik Vogt ---
Update: We've stepped through the code with gdb and noticed that the change in
lra-lives.c has nothing to do with our observations. The new condition there
is never executed, so it must be just the change in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #34 from Dominik Vogt ---
The patch in comment 33 fixes the s390 regression. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #4 from Dominik Vogt ---
Now this is the result of my efforts of reducing the original large test
program to a minimum.
---
struct s_t
{
unsigned f1: 8;
unsigned f2: 24;
};
bool foo(int a, int **pp, s_t **pps, void *s, int *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #5 from Dominik Vogt ---
Created attachment 36509
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36509&action=edit
test program and debug output
test program and debug output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #7 from Dominik Vogt ---
Almost. Note the strange bit numbering on s390. The highest order bit in any
operation always has the number 0, and the lowest order bit has the highest
number. So the 8-bit-move instruction "mvi" stores a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #8 from Dominik Vogt ---
Snippet of the assembly code from the test program posted in comment 4:
good compiler:
==
# r1 is 0x**XX (XX = value to store in the f1 field)
# r3 is the target address (ps)
# r9 is 0x**
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #9 from Dominik Vogt ---
> or %r1,%r2 # 32-bit or r1 := r1 | r2 -> 0xXX00
This should be
or %r1,%r2 # 32-bit or r1 := r1 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #10 from Dominik Vogt ---
This is what's happening:
Before the dse2 pass, there is a store instruction (25) followed by a read
instruction later (29):
---
# store first byte
(insn 25 135 136 4 (set (mem/j:QI (reg/v/f:DI 2 %r2 [orig:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #11 from Dominik Vogt ---
This is the bug report for the problem that the patch fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
Target Milestone: ---
The authors of the Ethereum project seem to assume that cgo can handle the code
below in a sensible way, but when using the -gccgo option that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #14 from Dominik Vogt ---
This is the thread discussing the patch that introduced the if-condition above
to ao_ref_from_mem:
https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01638.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #15 from Dominik Vogt ---
The original problem was that a 4-byte load (or whatever) from memory M into an
8-byte-register on bigendian machines is represented by a memory reference of
size 8 starting at M-4? This problem was present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #17 from Dominik Vogt ---
> So does [patch] fix the issue?
Yes. The testsuite on 64-bit and 31-bit systems has no regressions with the
patch either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #19 from Dominik Vogt ---
This is a cleaner test case for s390/s390x. If there was a way to tell gcc
"all registers except the first three argument registers are not available",
the test should be fairly easy to convert to other targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #20 from Dominik Vogt ---
Created attachment 36553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36553&action=edit
Dejagnu test case for s390/s390x.
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 se
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 kil
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 informatio
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=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 Gong'
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 t
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 #10 from Dominik Vogt ---
We cannot reproduce the crash on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #1 from Dominik Vogt ---
It seems that the DWARF library is unable to handle DW_AT_specification:
-- snip --
<1><7b4>: Abbrev Number: 27 (DW_TAG_variable)
<7b5> DW_AT_specification: <0x8b>
<7b9> DW_AT_decl_file : 13
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&action=edit
Experimental fix
The attached patch fixes the problem for us by skipping DW_TAG_variable DWARF
info that only co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #4 from Dominik Vogt ---
@comment 2
I can't see anything special that the file does:
-- secp256.go --
package secp256k1
/*
#cgo CFLAGS: -I./secp256k1
...
#include "./secp256k1/src/secp256k1.c"
*/
import "C"
-- END --
Then in
-- s
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&action=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=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=67976
--- Comment #4 from Dominik Vogt ---
The patch behind the link in comment 2 fixes the problem.
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
Created attachment 36669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36669&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #1 from Dominik Vogt ---
Created attachment 36675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36675&action=edit
Experimental fix.
The attached patch fixes the problem in the "go" tool by forcing the
--whole-archive linker op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #5 from Dominik Vogt ---
Great, thanks! My internal customer has confirmed that this patch fixes his
problem with Ethereum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #5 from Dominik Vogt ---
Any opinions on the patch in comment 3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #6 from Dominik Vogt ---
> My internal customer has confirmed that this patch fixes his problem with
> Ethereum.
(He had verified the patch I sent, not yet the patch that was committed.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #7 from Dominik Vogt ---
All right, I'll try to extract a minimal test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #8 from Dominik Vogt ---
Created attachment 36750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36750&action=edit
Test case
This is the requested minimal test program.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #1 from Dominik Vogt ---
These entries looks screwed to me:
-- snip --
32: 1024 [32: 1024] @ ...
#0x8000c44b ...allocatePersistent1K ... mprof_test.go:43
#0x8000c595 ...TestMemoryProfiler ... mprof_test.go:65
...
0: 0 [1: 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #4 from Dominik Vogt ---
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-new.c:14
#1 0x8000c32c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #5 from Dominik Vogt ---
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.
pprof_test.allocatePersistent1K+0x23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #7 from Dominik Vogt ---
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, not to be printed out as a real addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #8 from Dominik Vogt ---
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" {
// only works if fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #10 from Dominik Vogt ---
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. But given a function's return addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #13 from Dominik Vogt ---
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 minus 1).
(2) The address from (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #14 from Dominik Vogt ---
Created attachment 34773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34773&action=edit
Experimental fix
The attached patch is a sketch of a possible fix (at the expense of duplicating
some code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #15 from Dominik Vogt ---
P.S.: The patch only addresses s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #17 from Dominik Vogt ---
runtime.Callers is not called in this test case, so changing it won't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #18 from Dominik Vogt ---
Created attachment 34788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34788&action=edit
Different fix
How about this patch to the callback() function in go-callers.c to modify the
incoming pc. The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #20 from Dominik Vogt ---
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=32, keep_thunks=keep_thunks@en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #22 from Dominik Vogt ---
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 #29 from Dominik Vogt ---
(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
> represent inlined functions.
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #35 from Dominik Vogt ---
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. Determining the size of the call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #29 from Dominik Vogt ---
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 to a more expensive mechanism wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #4 from Dominik Vogt ---
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
if l != float64(i)
but if yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #5 from Dominik Vogt ---
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 not compile with -ffp-contract=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #6 from Dominik Vogt ---
(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 it on the Go issue
> tracker at h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #10 from Dominik Vogt ---
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 of the above patches applied?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #11 from Dominik Vogt ---
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 ---
With today's HEAD, the ICE in libgo is gone (s390x). Thanks.
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
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 ---
> execv(argv[0], &argv[1]);
^^^ ^^^
1 2
Sorry.
301 - 400 of 464 matches
Mail list logo
