Re: Go in gcc 4.7

Andreas Schwab writes: >> I suspect that the error of using "int" is one of the reasons why >> makecontext has been removed from POSIX. Thought I don't know why it >> was not replaced with a proper version. > > See >

Re: Go in gcc 4.7

Ian Lance Taylor writes: > Andreas Schwab writes: > >> Dennis Clarke writes: >> >>> for (argno = 0; argno < argc; argno++) { >>> if (argno < 6) >>> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >>> else >>> *tsp++ = va_arg(a

Re: Go in gcc 4.7

Andreas Schwab writes: > Dennis Clarke writes: > >> for (argno = 0; argno < argc; argno++) { >> if (argno < 6) >> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >> else >> *tsp++ = va_arg(ap, long); > > This is broken. T

Re: Go in gcc 4.7

On 13 January 2012 11:51, Dennis Clarke wrote: > >> Dennis Clarke writes: >> >>>      for (argno = 0; argno < argc; argno++) { >>>              if (argno < 6) >>>                      *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >>>              else >>>                      *tsp++ = va_arg(ap

Re: Go in gcc 4.7

> Dennis Clarke writes: > >> for (argno = 0; argno < argc; argno++) { >> if (argno < 6) >> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >> else >> *tsp++ = va_arg(ap, long); > > This is broken. The arguments are of type

Re: Go in gcc 4.7

Dennis Clarke writes: > for (argno = 0; argno < argc; argno++) { > if (argno < 6) > *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); > else > *tsp++ = va_arg(ap, long); This is broken. The arguments are of type int, n

Re: Go in gcc 4.7

Dennis Clarke writes: > Stuff from the opensolaris project isn't going to help here is it ? makecontext is inherently processor/ABI dependent. That looks like a SPARC version. It's fairly easy to write makecontext/getcontext/ setcontext for any specific processor/ABI. I don't really understan

Re: Go in gcc 4.7

> Joel Sherrill writes: > >> On 01/12/2012 12:16 PM, Andreas Schwab wrote: >>> Ian Lance Taylor writes: >>> The functions required are makecontext, getcontext, and setcontext. >>> Note that these functions are obsolescent in POSIX.1-2004 and removed >>> from POSIX.1-2008. >> Are there any a

Re: Go in gcc 4.7

Joel Sherrill writes: > On 01/12/2012 12:16 PM, Andreas Schwab wrote: >> Ian Lance Taylor writes: >> >>> The functions required are makecontext, getcontext, and setcontext. >> Note that these functions are obsolescent in POSIX.1-2004 and removed >> from POSIX.1-2008. > Are there any alternatives

Re: Go in gcc 4.7

On 01/12/2012 12:16 PM, Andreas Schwab wrote: Ian Lance Taylor writes: The functions required are makecontext, getcontext, and setcontext. Note that these functions are obsolescent in POSIX.1-2004 and removed from POSIX.1-2008. Are there any alternatives? It is bad that Go is already startin

Re: Go in gcc 4.7

Andreas Schwab writes: > Ian Lance Taylor writes: > >> The functions required are makecontext, getcontext, and setcontext. > > Note that these functions are obsolescent in POSIX.1-2004 and removed > from POSIX.1-2008. I know, but they were removed with no adequate replacement. POSIX suggests t

Re: Go in gcc 4.7

Ian Lance Taylor writes: > The functions required are makecontext, getcontext, and setcontext. Note that these functions are obsolescent in POSIX.1-2004 and removed from POSIX.1-2008. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 2

Re: Go in gcc 4.7

Joel Sherrill writes: > FWIW Go used to work well on RTEMS but recent changes have added > to the required set of OS APIs required and we are missing ucontext.h > currently. If someone wants to volunteer to help us out on implementing > that, it would be appreciated. I'd be happy to describe wh

Re: Go in gcc 4.7

Richard Guenther writes: > On Wed, Jan 11, 2012 at 5:43 AM, Ian Lance Taylor wrote: >> The Go language is closing in what we are calling Go version 1.  This >> will be a long-term stable release of Go, with no language or library >> API changes.  Go 1 is described here: > > There is still no off

Re: Go in gcc 4.7

On 01/12/2012 03:59 AM, Rainer Orth wrote: Ian Lance Taylor writes: Therefore not on Solaris 10 or even a baseline Solaris 8 at all. That seems to be an issue given this : People should be able to write Go programs and expect that they will continue to compile and run without

Re: Go in gcc 4.7

Ian Lance Taylor writes: >> Therefore not on Solaris 10 or even a baseline Solaris 8 at all. >> >> That seems to be an issue given this : >> >> People should be able to write Go programs and expect >> that they will continue to compile and run without >> change, on a timescale of year

Re: Go in gcc 4.7

On Wed, Jan 11, 2012 at 5:43 AM, Ian Lance Taylor wrote: > The Go language is closing in what we are calling Go version 1.  This > will be a long-term stable release of Go, with no language or library > API changes.  Go 1 is described here: There is still no official ABI, right? So no chance of

Re: Go in gcc 4.7

Dennis Clarke writes: > The Go 1 release will be available in source and binary form for at least > these platforms: > > FreeBSD 7+: amd64, 386 > Linux 2.6+: amd64, 386, arm > OS X (Snow Leopard + Lion): amd64, 386 > Windows (2000 + later): amd64, 386 > > Therefore

Re: Go in gcc 4.7

Re "go" for Solaris I see this : http://code.google.com/p/gofrontend/issues/detail?id=6 Not sure what the status in the mainline is but I am willing to do a checkout and build and see what goes wrong. I have 4.6.2 well done on Sparc Solaris 8 and that seems like a good place to start. Denni

Re: Go in gcc 4.7

> The Go language is closing in what we are calling Go version 1. This > will be a long-term stable release of Go, with no language or library > API changes. Go 1 is described here: > > https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE per that do

Go in gcc 4.7

The Go language is closing in what we are calling Go version 1. This will be a long-term stable release of Go, with no language or library API changes. Go 1 is described here: https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE The expected completi