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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Any expected date on a 4.7 RC ?
- --
- --
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla.
On Thu, Jan 12, 2012 at 3:15 PM, Dennis Clarke wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Any expected date on a 4.7 RC ?
When it's ready. Which we'd usually expect it to be around the
beginning of April.
Richard.
>> Any expected date on a 4.7 RC ?
>
> When it's ready. Which we'd usually expect it to be around the
> beginning of April.
cool. thank you.
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis
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
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
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
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
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
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
> bkoz pointed out that I forgot to update invoke.texi about
> -fabi-version=6. Applying to trunk
I've been thinking about this.
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
1. compile libstdc++
On Thu, 12 Jan 2012, Benjamin Kosnik wrote:
> I think a compelling case could be made to ship 4.7 with a
> configure-time flag that sets the default C++ dialect to C++11.
I think that's a bad idea; having too many ways to configure things will
cause undue confusion. But if someone really wants
On 12 January 2012 19:16, Benjamin Kosnik wrote:
>
> I think a compelling case could be made to ship 4.7 with a
> configure-time flag that sets the default C++ dialect to C++11.
>
> So, I would propose
>
> --with-std = dialect
>
> or
>
> --with-std-version=c dialect default, c++ dialect default
>
>
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
On 01/12/2012 02:16 PM, Benjamin Kosnik wrote:
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
Right, so people can use -fabi-version=0 and still use the installed
libstdc++.
I think a compelling
On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
not be able to change anything significant in .so.7 once it's
available in 4.7 and we'll have to create a .so.8 for more changes..
Wait, what? Are you planning to move to .so.7
On 12 January 2012 21:03, Jason Merrill wrote:
> On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
>>
>> And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
>> not be able to change anything significant in .so.7 once it's
>> available in 4.7 and we'll have to create a .so.8 for more
> 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
Snapshot gcc-4.5-20120112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
On Wed, 2012-01-11 at 12:29 -0500, Vladimir Makarov wrote:
> There is no visible effect of the patch on SPECFP2000 performance and
> size (the size increase is only about 0.02%) for x86 and x86-64.
>
> The patch does worsen performance of SPECINT2000 on x86 (about 0.5%) and
> x86-64 (about 0.3%)
22 matches
Mail list logo