https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
Michael Hudson-Doyle changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #12 from Michael Hudson-Doyle
---
Ah OK, yes that fixes the failure. Does this mean all uses of
SET_RESTORE_ROUND* should be using math_opt_barrier / math_force_eval to avoid
this issue? Sounds awkward. I guess having a macro to cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #10 from Michael Hudson-Doyle
---
FWIW, I see a similar error on ppc64el with what looks like a similar cause. (I
also see other errors that do not go away with s/O3/O2/ so that might be
something slightly different).
O3:
(kinetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #9 from Michael Hudson-Doyle
---
I uploaded the object file with the bad code to
https://people.canonical.com/~mwh/e_j1f128.os.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #8 from Michael Hudson-Doyle
---
I just changed
z = xx * xx;
to
z = math_opt_barrier(xx * xx);
which perhaps isn't sufficient.
But my reading of the assembly is that the issue is that some of the math code
is being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #6 from Michael Hudson-Doyle
---
Are there any tips as to how to diagnose this further? I tried putting a
math_opt_barrier on this line:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/ldbl-128/e_j1l.c;h=54c457681ae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #3 from Michael Hudson-Doyle
---
Certainly this could be "handled" by bumping the tolerance I guess. Not sure
how to tell if that is appropriate though...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #1 from Michael Hudson-Doyle
---
oops forgot the link to my glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=29463
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.hudson at canonical dot com
Target Milestone: ---
Initially reported here, but more likely to be a gcc issue: if I build glibc
with gcc 12 and -O3 (as is the default in Debian/Ubun
: go
Assignee: ian at airs dot com
Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
Target Milestone: ---
Running commands like this on Ubuntu trusty ppc64le:
$ go get github.com/juju/juju/...
$ cd $GOPATH/src/github.com/juju/juju
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
Target Milestone: ---
As reported at
https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1472650, any
gccgo
: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
Target Milestone: ---
https://github.com/golang/go/issues/11469 /
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353
Michael Hudson-Doyle changed:
What|Removed |Added
CC||michael.hudson at canonical
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #6 from Michael Hudson-Doyle
---
Which version were you using? I've never been able to reproduce it with
anything newer than the 4.9 series. I'd love to know what the fix was so we
can investigate backporting it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #4 from Michael Hudson-Doyle
---
Well, it seems to report that __morestack_segments &
__morestack_current_segment are always NULL for all threads. I don't
understand the morestack code perfectly, but this seems a bit unlikely to
act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #2 from Michael Hudson-Doyle
---
Oh, I was wrong in my initial comment. Setting a breakpoint like this:
(gdb) br *0x7971
Breakpoint 5 at 0x7971: file
../../../src/libgcc/config/i386/morestack.S, line 512.
(gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001
--- Comment #1 from Michael Hudson-Doyle
---
Created attachment 34175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34175&action=edit
very small reproducer
Well, here is a very small reproducer indeed. gccgo-go run boom.go fails ~50%
of
Assignee: ian at airs dot com
Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
Created attachment 34054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34054&action=edit
gdb session showing the crash
Hi,
This is probably not going to be
18 matches
Mail list logo
