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 different Go implementations to interoperate? Are the ABIs that the different implementations use documented somewhere? Definitely though this is worth mentioning in gcc-4.7/changes.html. Richard. > https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE > > The expected completion date is late February. > > My goal with gccgo is to include a complete Go 1 implementation with the > gcc 4.7 release. Therefore, I plan to continue to patch the code in > gcc/go and libgo. There shouldn't be any major changes, but there will > be various minor ones. Since this code is only built optionally, it > should not affect the rest of the release process. > > Please let me know about any objections or concerns. > > Ian
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 years. >> >> In keeping with the spirit of that vision what are the issues that block a >> port to Solaris today? Are there specific bugids I can look at ? > > There are two different Go compilers. The list of systems on which the > Go release will be available is for the other Go compiler, not gccgo. > The gccgo compiler will be part of gcc releases as usual. The gccgo > compiler has worked on Solaris in the past; current mainline is > reportedly not working on Solaris, but I intend to fix that if nobody > beats me to it. It even used to work on IRIX 6.5 in the past, but that is broken in pretty much the same way as the Solaris port right now. Unfortunately, I cannot tell when I'll have a chance to look into the Solaris problems; at least on x86, the 32-bit port continues to work fine. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
4.7 RC ?
-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...@blastwave.org | Respect for open standards. | +-+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) iEYEARECAAYFAk8O6ugACgkQHZNscvo1tEuVHACfU3BP6IvjF6ifEqH9VM/emDfH EDMAn1dOUcNOelZU+z9Z81IWrQLE8foV =tWIW -END PGP SIGNATURE-
Re: 4.7 RC ?
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.
Re: 4.7 RC ?
>> 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 Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
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 change, on a timescale of years. In keeping with the spirit of that vision what are the issues that block a port to Solaris today? Are there specific bugids I can look at ? There are two different Go compilers. The list of systems on which the Go release will be available is for the other Go compiler, not gccgo. The gccgo compiler will be part of gcc releases as usual. The gccgo compiler has worked on Solaris in the past; current mainline is reportedly not working on Solaris, but I intend to fix that if nobody beats me to it. It even used to work on IRIX 6.5 in the past, but that is broken in pretty much the same way as the Solaris port right now. Unfortunately, I cannot tell when I'll have a chance to look into the Solaris problems; at least on x86, the 32-bit port continues to work fine. 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. We had decent Go test results on a handful of architectures. Rainer -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
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 official ABI, right? So no chance of different Go > implementations > to interoperate? Are the ABIs that the different implementations use > documented > somewhere? It doesn't make too much sense to speak of an official ABI for Go in general. gccgo uses the usual C ABI on any given system. The way that gccgo represents Go types in C terms is documented at: http://golang.org/doc/gccgo_install.html#C_Interoperability . Though, as noted, some of the implementations are still subject to change, so in that sense there is no final ABI. The 6g and gccgo compilers are never going to interoperate. 6g uses a different approach to compilation, a different object file format, a different calling convention, etc., all in the name of fast compilation rather than fast execution. > Definitely though this is worth mentioning in gcc-4.7/changes.html. Yes, will do. Ian
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 what is needed but I can't help much with the actual implementation. The functions required are makecontext, getcontext, and setcontext. These are standard System V functions. makecontext sets up a new execution context: basically, a stack and a PC, which will start running when something calls setcontext. getcontext is basically setjmp. setcontext is basically longjmp. Ian
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 214B 8276 4ED5 "And now for something completely different."
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 that you can simply use pthreads, but that does not suffice for Go's needs. Ian
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 starting out dependent on obsolete methods. :( FWIW these should be straightforward to implement on RTEMS. They just have to wrap the internal routines used for thread context management. I stubbed them out so Go would continue to build. Andreas. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
> 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++.so with -fabi-version=6, and run the testsuites with the default abi (2) and have everything work. 2. compile libstdc++.so with the default abi and run the testsuites with -fabi-version=6. (Haven't tested this one completely yet.) Nothing tricky seems to be instantiated. That gives us a wider field of options for dealing with ABI issues... Here's my favorite idea at the moment for dealing with what we should be trying to encourage, ABI experimentation as part of GCC's mission for both technical excellence and liberty in computing. 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 be added to the top-level gcc configure and documented here: as: http://gcc.gnu.org/install/configure.html --with-std=dialect[,dialect] Specify a string that identifies the -std=dialect defaults for the built compiler and any associated runtimes. Default values are gnu99, g++98. For example, -std=gnu11,gnu++11 would build a compiler whose default language standards for "C" and C++ would be the GNU extensions to the C11 and C++11 standards. Then, I believe for C++ targets defaulting to C++11, then the language would be set to -fabi-version=6 and any other changes, and for the library, we'd use .so.7 and namespace versioning, and do the basic_string swap to __gnu_cxx::__versa_string (or alias it? hmm) and any other changes. So. Why do it this way? Because I think this would be an easier way for maintainers and other interested parties to experiment with changes. If we are happy and things look promising, then these people can lobby the rest of the community (with their collected experimental evidence) to change the language defaults. Or not, since people will now be able to just set it themselves if they feel strongly about the issue. I suspect that the standard practice in the wider communities and/or sub-communities will become clear with a mechanism like this. At least, we'll have a better idea of which sub-communities care and which don't. That's still better than what we've got now... it's been a mighty long time to be at -fabi-version=2 and libstdc++.so.6.. Lemme know what you think. best, benjamin
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
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 that and really knows what they are doing, it may be possible for them to do something with --with-specs. (C deliberately has not been moved to gnu99 as default because we don't have a -Wc90-c99-compat or similar option to warn about things different between C90 and C99, so anyone using -pedantic to warn about things outside C90 wouldn't be able just to use -pedantic -Wc90-c99-compat with a gnu99 default, they'd have to set the standard back to gnu89 as well. Given such an option - which should generate warnings, not pedwarns, for the cases that are presently pedwarn-if-pedantic-if-C90 (and a few other cases), changing the default to gnu99 would make sense - in Stage 1.) -- Joseph S. Myers jos...@codesourcery.com
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
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 > > be added to the top-level gcc configure and documented here: > > as: > > http://gcc.gnu.org/install/configure.html > > --with-std=dialect[,dialect] > Specify a string that identifies the -std=dialect defaults for the > built compiler and any associated runtimes. Default values are > gnu99, g++98. For example, -std=gnu11,gnu++11 would build a > compiler whose default language standards for "C" and C++ would be > the GNU extensions to the C11 and C++11 standards. I like the idea, but not very strongly. I can live with having to say -std=c++11 (which I do via shell functions or scripts) My completely unfounded prediction is that many G++ users will move to C++11 a lot quicker than the C community moved to C99. > Then, I believe for C++ targets defaulting to C++11, then the language > would be set to -fabi-version=6 and any other changes, and for the > library, we'd use .so.7 and namespace versioning, and do the > basic_string swap to __gnu_cxx::__versa_string (or alias it? hmm) > and any other changes. As an aside, how do you feel about starting to make those ABI breaking changes in the __7 versioned namespace? There are changes we know we need to make for C++11 conformance, but can't without breaking the ABI. If users explicitly select an incompatible ABI via the versioned namespace and .so.7 then there's no reason not to give them the best possible C++11 support we can, right? 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..
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? It is bad that Go is already starting > out dependent on obsolete methods. :( I would be glad to use alternatives but I'm not aware of any. The getcontext and setcontext functions are easy. The harder one is makecontext. POSIX appears to be assuming that any use of makecontext can be replaced with pthread_create, but if you care about efficiency that simply isn't true. Ian
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
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 case could be made to ship 4.7 with a configure-time flag that sets the default C++ dialect to C++11. I don't think so. Maybe 4.8. I expect more mangling fixes in the future; most notably, we don't test for instantiation-dependent expressions, so our mangling oversimplifies some symbols. I ought to open a PR for this. Jason
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
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 in 4.7? Jason
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
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 changes.. > > > Wait, what? Are you planning to move to .so.7 in 4.7? Nope, but the default is still v6, but configuring with --enable-symvers=gnu-versioned-namespace causes the library to be built as .so.7 (see the fix for PR 48698), so users of 4.7 will be able to build a .so.7 and there's no way to put that cat back in the bag once it's out. But maybe I've misunderstood the plan for v7 w.r.t versioned namespaces, and I've just realised that with versioned namespaces enabled we could have a .so.7 that includes both std::__7::foobar and std::__8::foobar, without needing to bump the library to .so.8
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? It is bad that Go is already starting
>> out dependent on obsolete methods. :(
>
> I would be glad to use alternatives but I'm not aware of any.
>
> The getcontext and setcontext functions are easy. The harder one is
> makecontext. POSIX appears to be assuming that any use of makecontext
> can be replaced with pthread_create, but if you care about efficiency
> that simply isn't true.
>
> Ian
>
Stuff from the opensolaris project isn't going to help here is it ?
void
makecontext(ucontext_t *ucp, void (*func)(), int argc, ...)
{
greg_t *reg;
long *tsp;
char *sp;
int argno;
va_list ap;
size_t size;
reg = ucp->uc_mcontext.gregs;
reg[REG_PC] = (greg_t)func;
reg[REG_nPC] = reg[REG_PC] + 0x4;
/*
* Reserve enough space for a frame and the arguments beyond the
* sixth; round to stack alignment.
*/
size = sizeof (struct frame);
size += (argc > 6 ? argc - 6 : 0) * sizeof (long);
/*
* The legacy implemenation of makecontext() on sparc has been to
* interpret the uc_stack.ss_sp member incorrectly as the top of the
* stack rather than the base. We preserve this behavior here, but
* provide the correct semantics in __makecontext_v2().
*/
sp = (char *)(((uintptr_t)ucp->uc_stack.ss_sp - size) &
~(STACK_ALIGN - 1));
/*
* Copy all args to the stack, and put the first 6 args into the
* ucontext_t. Zero the other fields of the frame.
*/
/* LINTED pointer cast may result in improper alignment */
tsp = &((struct frame *)sp)->fr_argd[0];
bzero(sp, sizeof (struct frame));
va_start(ap, argc);
for (argno = 0; argno < argc; argno++) {
if (argno < 6)
*tsp++ = reg[REG_O0 + argno] = va_arg(ap, long);
else
*tsp++ = va_arg(ap, long);
}
va_end(ap);
reg[REG_SP] = (greg_t)sp - STACK_BIAS; /* sp (when done) */
reg[REG_O7] = (greg_t)resumecontext - 8;/* return pc */
}
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
gcc-4.5-20120112 is now available
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/gcc-4_5-branch revision 183143 You'll find: gcc-4.5-20120112.tar.bz2 Complete GCC MD5=14f78ced5346799d433c4eb428e8fb50 SHA1=1271ee1e05fb8a11476d1510e04dc80d359eeead Diffs from 4.5-20120105 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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 understand why POSIX removed the functions. Ian
Re: IRA issue with shuffle copies...
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%). x86-64 SPECINT200 code size increase is about > 0.05% and there is no visible change in code size on x86. > > So I'd say the patch does not work for x86/x86-64. Pat ran SPEC2000 and SPEC2006 and we had some wins and some loses. We'll dig into a couple of the loses to see if we can learn anything and report back if we do. Thanks for doing the x86* runs. Peter
