[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #16 from Stephen Kim --- (In reply to Andrew Pinski from comment #15) > Let's start over. crt1.o in glibc should support calling main that is > located in the shared library. > If it does not then there is a bug there. > Sorry. I

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #19 from Stephen Kim --- Thank you for all of your comments! I have talked with our team members again. It seems that there has been miscommunication. They seemed to have intended that Go tools should give Scrt1.o. However, as Go to

[Bug go/86289] New: Cgo integer constant overflow for 64 bits (unsigned) int

Priority: P3 Component: go Assignee: ian at airs dot com Reporter: stephen.kim at oracle dot com CC: cmang at google dot com Target Milestone: --- I think the bug report is not the best format for this issue but that's the only I have. Let me start wit

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289 Stephen Kim changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289 Stephen Kim changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED

[Bug go/86331] New: the gccgo's "go" tool looks like failing to invoke any sub go command

everity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: stephen.kim at oracle dot com CC: cmang at google dot com Target Milestone: --- It seems that putting back a new version of go to gcc8 triggers the issue I woul

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Stephen Kim changed: What|Removed |Added CC||stephen.kim at oracle dot com --- Comment

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #3 from Stephen Kim --- Created attachment 44327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44327&action=edit strace -f go run hello.go strace -f go run hello.go

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #4 from Stephen Kim --- Just in case, this system also includes Google's gc. With the gc, everything that fails with gccgo like this seems all fine. Thus, I think this problem might be in the top-level "go tool," which parses the comm

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #8 from Stephen Kim --- After applying your patch, the issue seems to have gone away.

[Bug driver/88262] New: gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: stephen.kim at oracle dot com Target Milestone: --- I am not yet certain that this is a gcc bug or user's fault. That's why I am filing a bug here to

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 Stephen Kim changed: What|Removed |Added CC||stephen.kim at oracle dot com --- Comment

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #5 from Stephen Kim --- (In reply to jos...@codesourcery.com from comment #3) > As of October 2017, glibc has a testcase that having main in a shared > library works - that's a valid use case, which should work with crt1.o. > If it

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 Stephen Kim changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #11 from Stephen Kim --- (In reply to Andrew Pinski from comment #9) > (In reply to jos...@codesourcery.com from comment #8) > > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote: > > > > > The gli

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #12 from Stephen Kim --- (In reply to jos...@codesourcery.com from comment #8) > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote: > > > The glibc commit that triggered

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #13 from Stephen Kim --- (In reply to Andreas Schwab from comment #7) > If you think you have found a bug in glibc, then this is not the right place > to report it. I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc p

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #14 from Stephen Kim --- (In reply to Andreas Schwab from comment #7) > If you think you have found a bug in glibc, then this is not the right place > to report it. I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc p