bump Autoconf and Libtool versions?
Hi Paolo, all, any plans to bump Autoconf and Libtool versions used in GCC? I'd like to see 2.68 and 2.4.0 in 4.6 in due course of course (i.e., after both have been released, and before stage 1 ends). Should I proposed patches then? Thanks, Ralf
Re: bump Autoconf and Libtool versions?
On 09/19/2010 11:05 AM, Ralf Wildenhues wrote: Hi Paolo, all, any plans to bump Autoconf and Libtool versions used in GCC? I'd like to see 2.68 and 2.4.0 in 4.6 in due course of course (i.e., after both have been released, and before stage 1 ends). Regarding Libtool, sure. However, we need to ascertain if and how the new sysroot functionality affects GCC (in particular if the configure options are incompatible). Regarding Autoconf, I'd rather see a further upstream release before upgrading, and also waiting a month after the release. I'm not comfortable with forcing GCC contributors to use a release with known regressions (though not affecting GCC). On the other hand, given the above plan I would be okay with upgrading Autoconf during early stage 3. Paolo
Re: bump Autoconf and Libtool versions?
* Paolo Bonzini wrote on Sun, Sep 19, 2010 at 11:11:30AM CEST: > On 09/19/2010 11:05 AM, Ralf Wildenhues wrote: > >any plans to bump Autoconf and Libtool versions used in GCC? > >I'd like to see 2.68 and 2.4.0 in 4.6 in due course of course > >(i.e., after both have been released, and before stage 1 ends). > > Regarding Libtool, sure. However, we need to ascertain if and how > the new sysroot functionality affects GCC (in particular if the > configure options are incompatible). Of course. > Regarding Autoconf, I'd rather see a further upstream release before > upgrading, and also waiting a month after the release. I'm not > comfortable with forcing GCC contributors to use a release with > known regressions (though not affecting GCC). > > On the other hand, given the above plan I would be okay with > upgrading Autoconf during early stage 3. That sounds all very reasonable, thanks. Cheers, Ralf
Re: Reverse mapping from decl uid
On Sat, Sep 18, 2010 at 9:26 PM, Uday P. Khedker wrote: > > Given a tree node, we can get its uid by using DECL_UID(node). > > Given a uid, is it possible to directly get the tree node that > corresponds to it? I can of course make a list of nodes that I > am interested in but if there is an API, I would much rather > use it. Not in general, there is referenced_var which is such a mapping but is only valid for the decls a function references. Richard. > Thanks. > > Uday. > > P.S. : Earlier, I have written pretty complex code because I > didn't know some of the APIs :-( > > Trying to become wiser now :-) >
Re: [C++-0x] User-defined literals.
On 09/17/2010 08:25 AM, Ed Smith-Rowland wrote: > Thanks for any help you can give, Maybe Rodrigo would be interested in collaborating on this work? Rodrigo? Thanks, Paolo.
Re: [C++-0x] User-defined literals.
> Maybe Rodrigo would be interested in collaborating on this work? Sure I am! Please, let me a couple of days to re-read the C++ draft, and check this patch. Also, take in account that I'm in no way a GCC expert... but I'll do my best. Also I have a little patch on my own that might use some help... But this is for another post. Regards. -- Rodrigo
Re: [C++-0x] User-defined literals.
On 09/19/2010 02:37 PM, Rodrigo Rivas wrote: Maybe Rodrigo would be interested in collaborating on this work? Sure I am! Please, let me a couple of days to re-read the C++ draft, and check this patch. Also, take in account that I'm in no way a GCC expert... but I'll do my best. Also I have a little patch on my own that might use some help... But this is for another post. Regards. -- Rodrigo I would be delighted to collaborate. I got over my initial hump using a more generic lookup (like the standard says). I'll make another patch over the next day or two . I can parse strings: "sluggo"_xyz, u"facebeef"_LL, etc. I can parse the various char types: 'x'_foo etc. I'm looking at (besides input on what I've got currently): 1. A warning or error if a user chooses a suffix that gcc uses. I was surprised that 'w', 'q', 'i', 'j' and several others were used by gcc for floats. I won't be the only one. The standard is clear that implementations get first crack at these but it shouldn't be a mystery or a surprise when things don't work as expected. 2. Should we at least pedwarn about user not starting a suffix with an underscore? Probably. Non-underscore suffixen are reserved to the implementation but I think a user should be able to use one if it's not used by gcc though the user risks non-portability and potential but unlikely future breakage. 3. The big one: Getting the integer(long long) and float(long double) suffixes that are not used by gcc out of the preprocessor. Then we can build the calls. 4. If, for long long and long double the usual signature is not found, first look for a: _suffix(char*) and failing that: template _suffix(). So we'll need to make the lookup of these two signatures more complex.
gcc-4.3-20100919 is now available
Snapshot gcc-4.3-20100919 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100919/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 164424 You'll find: gcc-4.3-20100919.tar.bz2 Complete GCC (includes all of below) MD5=8101854e8ed093c3c8bc74945a79cf17 SHA1=0bb7870e03d2bb86f495addeaebc49d9cf981cfc gcc-core-4.3-20100919.tar.bz2C front end and core compiler MD5=adb4d205b58dcd426d1755295a712461 SHA1=2f2bb30f8c6a55b4e4a549ee5a9c06ca7ebfe825 gcc-ada-4.3-20100919.tar.bz2 Ada front end and runtime MD5=b398f984faa3f6f628b738fe614c9773 SHA1=393b236fc4de3f9fb1cbc97408edbf7043561895 gcc-fortran-4.3-20100919.tar.bz2 Fortran front end and runtime MD5=65d27a55148484b9d22f0d47c972d6dd SHA1=66a7dcfbb99ed80e6589823abe0a644d56497e9d gcc-g++-4.3-20100919.tar.bz2 C++ front end and runtime MD5=410855c03c494c3e00c587569da2b236 SHA1=f8a1217c75bb150382498434501a39523ec283ca gcc-java-4.3-20100919.tar.bz2Java front end and runtime MD5=ddaf1dafbbe7fa0381c06833354c52a6 SHA1=f772d7314f45ac7f2a6439e90f5479f28261e3ff gcc-objc-4.3-20100919.tar.bz2Objective-C front end and runtime MD5=4299c2de27838ec5f041b097db31ee26 SHA1=98d9a717b948ba96db5794847d33eb799b43f052 gcc-testsuite-4.3-20100919.tar.bz2 The GCC testsuite MD5=3218d994851b51995a73e111bd3af19e SHA1=1050b058060ed9b4f5f389ae173fe367c56856b3 Diffs from 4.3-20100912 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
[wwwdocs] PATCH for Re: new canadian mirror
On Thu, 16 Sep 2010, Sergey Ivanov wrote: > http://gcc.skazkaforyou.com > > location: Canada > > Please contact me about this mirror. Thanks, Sergey! I am adding this to our mirror list per the patch below. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.199 diff -u -3 -p -r1.199 mirrors.html --- mirrors.html14 Aug 2010 15:43:59 - 1.199 +++ mirrors.html19 Sep 2010 20:41:31 - @@ -35,6 +35,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin dot Sprinzl at tuwien dot ac dot at Bulgaria: http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks to igor at onlinedirect dot bg Canada: http://gcc.parentinginformed.com";>http://gcc.parentinginformed.com, thanks to James Miller (jmiller at parentinginformed dot com). +Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou dot com) China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/, thanks to David Deng (david99deng at yahoo dot com) France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 dot fr France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpmaint at irisa dot fr
, you may not
Yet," said the King, rub-bing his hands as if much pleased; "so now let the ju-ry--" "If one of you can tell what it means," said Al-ice (she had grown so large by this time that she had no fear of the King) "I should be glad to hear it. I don't think there's a grain of sense in it." The ju-ry all wrote down on their slates, "She doesn't think there's a grain of sense in it." But no one tried to tell what it meant. "If there's no sense in it," said the King, "that saves a world of work, you know, as we needn't try to find it. And yet I don't know," he went on, as he spread out the rhymes on his knee, and looked at them with one eye: "I seem to find some sense in them--'said I could not swim'--you can't swim, can you?" he added, turn-ing to the Knave. The Knave shook his head with a sigh. "Do I look like it?" he said. (Which it was plain he did not, as he was made of card board.) "All right, so far," said the King, and he went on: "'We know it to be true'--that's the ju-ry, of course--'I gave her one, they gave him two'--that must be what he did with the tarts, you know--" "But i <>
