Re: gcc & C++ instead of g++
Sorry, I'm gonna go to unsbscribe. On Wed, 2009-09-09 at 23:42 -0700, Ian Lance Taylor wrote: > Mohsen Pahlevanzadeh writes: > > > How do i write C++ with gcc instead of g++? > > The question is not appropriate for the mailing list g...@gcc.gnu.org. > It is appropriate for gcc-h...@gcc.gnu.org. Please take any followups > to gcc-help. Thanks. > > There is no particular reason to use gcc instead of g++. If you really > want to do so, there are two easy ways: 1) name your files with an > extension of .cc rather than .c; 2) use the -x c++ option. Note that if > you link with gcc, you will need to explicitly use -lstdc++. > > Ian
Problems with lambda implementation
Hello,
Recently I made some tests with lambda (mingw build) I found some
problems. Here they are:
1. Lambda and template type deduction.
Try this sample:
#include
#include
#include
#include
typedef std::function FnType;
template
FnType average_damp(T fn)
{
return [fn](double x) {return (x + fn(x)) / 2;};
}
int main(int argc, char* argv[])
{
auto fn = average_damp([](double x){return x * 2;});
std::cout << fn(10.0) << std::endl;
return 0;
}
This sample successfully built with VS 2010, but under gcc there are
some compilation errors:
P:\projects\Tests\Sandbox\C++0x\gcc43>g++ -std=c++0x -Os
-IP:\Projects\common\boost_1.36.0 lambda.cpp
In file included from
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/functional:70:0,
from lambda.cpp:4:
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional: In
static member function 'static void std::_F
unction_base::_Base_manager<_Functor>::_M_clone(std::_Any_data&, const
std::_Any_data&, std::false_type) [with _Functor
= average_damp(T) [with T = main(int, char**)::(double), FnType =
std::function]::(doubl
e), std::false_type = std::integral_constant]':
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:1543:8:
instantiated from 'static bool std::_
Function_base::_Base_manager<_Functor>::_M_manager(std::_Any_data&, const
std::_Any_data&, std::_Manager_operation) [wit
h _Functor = average_damp(T) [with T = main(int, char**)::(double),
FnType = std::function]::(double)]'
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:2013:6:
instantiated from 'std::function<_Res
(_ArgTypes ...)>::function(_Functor, typename __gnu_cxx::__enable_if<(!
std::is_integral::value), std::function<_Res(_Ar
gTypes ...)>::_Useless>::__type) [with _Functor = average_damp(T) [with T =
main(int, char**)::(double), FnType
= std::function]::(double), _Res = double, _ArgTypes =
double, typename __gnu_cxx::__enable_if<(
! std::is_integral::value), std::function<_Res(_ArgTypes
...)>::_Useless>::__type = std::function::_Usel
ess]'
lambda.cpp:11:51: instantiated from 'FnType average_damp(T) [with T =
main(int, char**)::(double), FnType = st
d::function]'
lambda.cpp:16:55: instantiated from here
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:1507:4:
error: no matching function for call to
'average_damp(T) [with T = main(int, char**)::(double), FnType =
std::function]::(doubl
e)::__lambda0(average_damp(T) [with T = main(int, char**)::(double),
FnType = std::function]::(double)&)'
lambda.cpp:11:25: note: candidates are: average_damp(T) [with T = main(int,
char**)::(double), FnType = std::fun
ction]::(double)
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional: In
static member function 'static void std::_F
unction_base::_Base_manager<_Functor>::_M_init_functor(std::_Any_data&, const
_Functor&, std::false_type) [with _Functor
= average_damp(T) [with T = main(int, char**)::(double), FnType =
std::function]::(doub
le), std::false_type = std::integral_constant]':
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:1555:4:
instantiated from 'static void std::_
Function_base::_Base_manager<_Functor>::_M_init_functor(std::_Any_data&, const
_Functor&) [with _Functor = average_damp(
T) [with T = main(int, char**)::(double), FnType =
std::function]::(double)]'
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:2014:6:
instantiated from 'std::function<_Res
(_ArgTypes ...)>::function(_Functor, typename __gnu_cxx::__enable_if<(!
std::is_integral::value), std::function<_Res(_Ar
gTypes ...)>::_Useless>::__type) [with _Functor = average_damp(T) [with T =
main(int, char**)::(double), FnType
= std::function]::(double), _Res = double, _ArgTypes =
double, typename __gnu_cxx::__enable_if<(
! std::is_integral::value), std::function<_Res(_ArgTypes
...)>::_Useless>::__type = std::function::_Usel
ess]'
lambda.cpp:11:51: instantiated from 'FnType average_damp(T) [with T =
main(int, char**)::(double), FnType = st
d::function]'
lambda.cpp:16:55: instantiated from here
s:/programming/mingw/lib/gcc/../../include/c++/4.5.0/tr1_impl/functional:1584:4:
error: no matching function for call to
'average_damp(T) [with T = main(int, char**)::(double), FnType =
std::function]::(doubl
e)::__lambda0(const average_damp(T) [with T = main(int,
char**)::(double), FnType = std::function]::(double)&)'
lambda.cpp:11:25: note: candidates are: average_damp(T) [with T = main(int,
char**)::(double), FnType = std::fun
ction]::(double)
What's wrong?
2. Lambdas and result_of or something similar.
How I can determine return type of lambda in compile time? As far as I
could understood there is no way to do so. Is it right?
--
Best Regards,
Sergey mailto:flex_fer...@artberg.ru
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
* Pedro Lamarão wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST: > 2009/8/26 Ralf Wildenhues: > > >> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration > >> >‘char* basename(const char*)’ > >> >/usr/include/string.h:601: error: ambiguates old declaration ‘const > >> >char* basename(const char*)’ > >> > >> The problem is that AC_CHECK_DECLS gets confused by overloaded > >> functions, and glibc 2.10 has overloaded declarations of basename > >> and some other string functions for const-correctness. > > > > Could you show the config.log snippet that shows the failed test? > > Is this a new error due to the autotools upgrade, or new due to > > glibc 2.10? > > I think this is new in glibc 2.10, for the reasons given by Jason Merrill > above. > I've discussed this problem with Jerry Quinn before, and he had a > tentative patch that worked for me. > As I understand things, this patch is on hold waiting for a solution > to the bootstrap comparison problem being discussed in another thread. > > I am waiting for a solution to these problems to continue work on the > std::sort gcc-in-cxx subproject; keeping all these patches up to date > with trunk is too difficult for me right now. > Currently, I have a patch to an old revision of the trunk. Well, can you post the patch, or did I somehow miss it on the list? I'd be particularly interested if it tries to fix the Autoconf test in some sensible way. Thanks, Ralf
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
2009/9/10 Ralf Wildenhues : > * Pedro Lamarão wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST: >> 2009/8/26 Ralf Wildenhues: >> I think this is new in glibc 2.10, for the reasons given by Jason Merrill >> above. >> I've discussed this problem with Jerry Quinn before, and he had a >> tentative patch that worked for me. >> As I understand things, this patch is on hold waiting for a solution >> to the bootstrap comparison problem being discussed in another thread. >> >> I am waiting for a solution to these problems to continue work on the >> std::sort gcc-in-cxx subproject; keeping all these patches up to date >> with trunk is too difficult for me right now. >> Currently, I have a patch to an old revision of the trunk. > > Well, can you post the patch, or did I somehow miss it on the list? > I'd be particularly interested if it tries to fix the Autoconf test > in some sensible way. I don't have it with me right now, but the solution is basically to replace AC_CHECK_DECL(basename) with AC_CHECK_FUNC(basename) in configure.ac. -- P.
MPC 0.7 officially released, please test and report your results!
Hi,
mpc-0.7 now has been released, you can get the package here:
http://www.multiprecision.org/index.php?prog=mpc&page=download
Here's the official announcement:
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-September/000554.html
Of particular interest in this release are bugfixes, especially for
complex division, and the introduction of mpc_pow used for folding
cpow{,f,l} inside GCC.
Note the complex "arc" functions are still missing and are now projected
to be available in a future release, probably 0.8.
Please download, compile and run "make check" for this release and post
your results as well your target triplet and the versions of your
compiler, gmp and mpfr. All platform results are welcome, but I am
especially interested in GCC's primary and secondary platform list.
Thanks,
--Kaveh
RTEMS SPARC ACATS Results (SVN head failures)
Hi, I have stepped back to make sure I had good results to compare against. So I have run ACATS on 4.3.4 and 4.4.x and SVN for sparc, powerpc, mips, arm, and i386. I am using the same binutils, gdb, newlib, and RTEMS. Only gcc changes. The first target to ask about is the SPARC. 4.3.4 - 2 FAILS: c380004 and c953002 4.4.1 - 2 FAILS: c380004 and c953002 svn -319 FAILS a85013b a87b59a a95001c a95074d a99006a aa2010a ac3207a ad7201a ad7203b ad7205b c250002 c34007j c34008a c35102a c37402a c37403a c380004 c38102d c38202a c3a1002 c41306a c41306b c41306c c41307d c43204g c45282b c45291a c46051a c51004a c59002c c64201b c64201c c650001 c74004a c74401k c74406a c761001 c761007 c83023a c85004b c85005a c85005b c85005c c85005d c85005e c85006a c85006b c85006c c85006d c85006e c85014a c85014b c85014c c85018a c85018b c87b26b c87b39a c87b45c c87b54a c910001 c910002 c910003 c91004b c91004c c91006a c92002a c92003a c92005a c92005b c92006a c930001 c93001a c93002a c93003a c93004a c93004b c93004c c93004d c93004f c93005a c93005b c93005c c93005d c93005e c93005f c93005g c93005h c93006a c93008a c93008b c940001 c940002 c940004 c940005 c940007 c940010 c940013 c940014 c940016 c94001a c94001b c94001c c94001e c94001f c94001g c94002a c94002b c94002d c94002e c94002f c94002g c94004a c94004b c94004c c94005a c94005b c94006a c94007a c94007b c94008a c94008b c94008c c94008d c94010a c94011a c94020a c940a03 c95008a c95009a c95010a c95011a c95012a c95021a c95022a c95022b c95033a c95033b c95034a c95034b c95035a c95040a c95040b c95040c c95040d c95041a c95065a c95065b c95065c c95065d c95065e c95065f c95066a c95067a c95071a c95072a c95072b c95073a c95074c c95076a c95078a c95080b c95082g c95085a c95085b c95085c c95085d c95085e c95085f c95085g c95085h c95085i c95085j c95085k c95085l c95085m c95085n c95085o c95086a c95086b c95086c c95086d c95086e c95086f c95087a c95087b c95087c c95087d c95088a c95089a c95090a c95092a c95093a c95095a c95095b c95095c c95095d c95095e c951001 c951002 c953001 c953002 c953003 c954001 c954010 c954011 c954012 c954013 c954014 c954015 c954016 c954017 c954018 c954019 c954020 c954021 c954022 c954023 c954024 c954025 c954026 c954a01 c954a02 c954a03 c960001 c960002 c960004 c97112a c97113a c97114a c97115a c97116a c97117a c97117b c97117c c97118a c97120a c97120b c97201a c97201b c97201c c97201d c97201e c97201g c97201h c97201x c97202a c97203a c97203b c97203c c97204a c97204b c97205a c97205b c97301a c97301b c97301c c97301d c97301e c97302a c97303a c97303b c97303c c97304a c97304b c97305a c97305b c97305c c97305d c97307a c974001 c974002 c974003 c974004 c974005 c974008 c974009 c974010 c974011 c974013 c974014 c99004a c99005a c9a003a c9a007a c9a009a c9a009c c9a009f c9a009g c9a009h c9a010a c9a011a c9a011b ca5004a cb20001 cb4013a cb41002 cb5001a cb5001b cb5002a cc1104c cc1207b cc1225a cc1310a cc3019c cc3106b cc3120b cc3207b cc3225a cc3601c cc3602a cd10002 cd2a91c cd2c11a cd5003e cd72a02 cxh3001 cxh3002 cxh3003 la14027 sparc-rtems4.10-gcc (GCC) 4.5.0 20090910 (experimental) [trunk revision 151592] Does any of this look familiar? Any feedback on the SPARC results would be appreciated. With this many new failures, I don't even know where to start reporting. :( -- 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
gcc-4.5-20090910 is now available
Snapshot gcc-4.5-20090910 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090910/ 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/trunk revision 151619 You'll find: gcc-4.5-20090910.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090910.tar.bz2 C front end and core compiler gcc-ada-4.5-20090910.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090910.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090910.tar.bz2 C++ front end and runtime gcc-java-4.5-20090910.tar.bz2 Java front end and runtime gcc-objc-4.5-20090910.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090910.tar.bz2The GCC testsuite Diffs from 4.5-20090903 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: hppa testsuite stalls?
On 09.09.2009 03:07, John David Anglin wrote: the testsuite on the hppa machine (gcc61 on the compile farm) has always hanged for me from time to time. However, lately (at least since I returned from vacation last Monday) it hangs every time. This is likely a kernel problem. There are long standing problems with testsuite timeouts and occassional hangs on linux. The frequency of these is kernel and hardware dependent. Is this a know problem? How should I investigate such problems? It makes proper testing on that platform rather impossible for me. It's very difficult as there's little relationship between cause and symptoms. If you come across a reproducible testcase, please report it to the parisc-linux list. if this is a debian parisc-linux system you might want to install expect-tcl8.3 (which removes the expect package) to avoid the timeouts. at least that works around the timeouts on the debian buildds. Matthias
Re: hppa testsuite stalls?
Matthias Klose wrote: > On 09.09.2009 03:07, John David Anglin wrote: >> > >> the testsuite on the hppa machine (gcc61 on the compile farm) has >>> always hanged for me from time to time. However, lately (at least >>> since I returned from vacation last Monday) it hangs every time. >> >> This is likely a kernel problem. There are long standing problems >> with testsuite timeouts and occassional hangs on linux. The frequency >> of these is kernel and hardware dependent. >> >>> Is this a know problem? How should I investigate such problems? It >>> makes proper testing on that platform rather impossible for me. >> >> It's very difficult as there's little relationship between cause >> and symptoms. If you come across a reproducible testcase, please >> report it to the parisc-linux list. > > if this is a debian parisc-linux system you might want to install > expect-tcl8.3 (which removes the expect package) to avoid the timeouts. > at least that works around the timeouts on the debian buildds. BTW, there was a patch just checked in to make sure ACATS tests time out properly instead of stalling: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00740.html Maybe it can help? cheers, DaveK
[gnat] stmt_group_free_list and gnu_stack_free_list in trans.c
Hello, What is the point of stmt_group_free_list and gnu_stack_free_list in trans.c? Why not always allocate a fresh node? Thanks, Oliver
