[Bug go/66303] New: runtime.Caller() returns infinitely deep stack frames on s390x

Priority: P3 Component: go Assignee: ian at airs dot com Reporter: e29253 at jp dot ibm.com CC: cmang at google dot com Target Milestone: --- Created attachment 35633 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35633action=edit Sample program

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #3 from Tatsushi Inagaki e29253 at jp dot ibm.com --- Created attachment 35641 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35641action=edit gdb session of callback() called from runtime.Caller(skip==3)

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #2 from Tatsushi Inagaki e29253 at jp dot ibm.com --- The first invocation of runtime.Caller() with skip==2 successfully detects kickoff() in callback(), and thus returns ok==true. The problem is that the succeeding invocations

[Bug go/63731] Fallback to netgo does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #27 from Tatsushi Inagaki e29253 at jp dot ibm.com --- (In reply to Ian Lance Taylor from comment #26) Tatsushi: are you asking about gccgo, or about gc? I'm asking about gccgo.

[Bug go/63731] Fallback to netgo does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #25 from Tatsushi Inagaki e29253 at jp dot ibm.com --- What is the most recommended way when we want to use the net package in a statically linked binary? My impression is that a statically linked binary also should call dlopen

[Bug go/65134] New: gccgo ignores the attribute constructor in a subdirectory

Priority: P3 Component: go Assignee: ian at airs dot com Reporter: e29253 at jp dot ibm.com CC: cmang at google dot com Created attachment 34813 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34813action=edit Example to reproduce the constructor problem

[Bug go/65134] gccgo ignores the attribute constructor in a subdirectory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134 --- Comment #2 from Tatsushi Inagaki e29253 at jp dot ibm.com --- (In reply to Ian Lance Taylor from comment #1) It's pretty ugly, but a workaround is to drop something like this into sub.go: var AlwaysFalse bool func init

[Bug go/65134] gccgo ignores the attribute constructor in a subdirectory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134 --- Comment #4 from Tatsushi Inagaki e29253 at jp dot ibm.com --- I see. Thanks a lot!

[Bug go/63812] Compilation error due to a large floating point constant truncated to integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63812 --- Comment #5 from Tatsushi Inagaki e29253 at jp dot ibm.com --- Submitted a pull request to Docker: https://github.com/docker/docker/pull/9233

[Bug go/63812] Compilation error due to a large floating point constant truncated to integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63812 --- Comment #4 from Tatsushi Inagaki e29253 at jp dot ibm.com --- Ian, Thank you very much for your helpful clarification. I confirmed that the unit test passes with both of GC and GCCGO, when we modify the test from: assertEquals(t

[Bug go/63812] Compilation error due to a large floating point constant truncated to integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63812 --- Comment #2 from Tatsushi Inagaki e29253 at jp dot ibm.com --- (In reply to Andrew Pinski from comment #1) This might be an issue in mpfr and not GCC if I read GCC's code correctly. Depending on how 2.22 is read in as a floating point value

[Bug go/63812] New: Compilation error due to a large floating point constant truncated to integer

: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: e29253 at jp dot ibm.com CC: cmang at google dot com GCCGO cannot compile the following program, while GC can compile and run the same program. This program is derived from