Re: RFH - Testing targets for the switch to C++
On Fri, 6 Apr 2012, Diego Novillo wrote: I have started testing the switch to C++ and there is a pile of testing to be done. The testing itself is trivial, but the number of targets that need to be tested is large and I don't have access to all these combinations. Hello, sorry for being slow, but the way things are presented is surprising to me. I would expect most problems to be related to the host, and more specifically the compiler used to initiate the build, not so much the target. Or is this aiming specifically for targets that only get cross-compilers and thus don't have stage 2 and haven't been tested with a C++ compiler yet? For build issues with other compilers, 50167 and 50177 are still open (last time I looked, I couldn't find the meta-bug about switching to C++ in stage1 to add them as blockers). -- Marc Glisse
Re: RFH - Testing targets for the switch to C++
On Sat, Apr 7, 2012 at 13:15, Marc Glisse wrote: > I would expect most problems to be related to the host, and more > specifically the compiler used to initiate the build, not so much the > target. Or is this aiming specifically for targets that only get > cross-compilers and thus don't have stage 2 and haven't been tested with a > C++ compiler yet? You are right that it is mainly an issue for the host. But some of the target code gets only exposed when building for that target, and I figured that the targets reported in gcc-testresults are tested in a variety of hosts. Hence my call for help. I want to get as much testing variety as possible. > For build issues with other compilers, 50167 and 50177 are still open (last > time I looked, I couldn't find the meta-bug about switching to C++ in stage1 > to add them as blockers). Thanks. I will take a look. If there is no meta bug, I'll create one. Diego.
Re: RFH - Testing targets for the switch to C++
For *-rtems* all test results are cross with tests run on simulators. We use a native compiler bulit from the same source for testing. Newlib is the C library and built at the same time. Do we need to enable any special flags from our existing configure? FWIW we have a few targets where the simulator is limited in memory and many tests fail. These get rejected because the mail message is too large. If someone is willing to help us trim things so the known failures get skipped, it would be appreciated. We would report more. :) --joel RTEMS Diego Novillo wrote: >On Sat, Apr 7, 2012 at 13:15, Marc Glisse wrote: > >> I would expect most problems to be related to the host, and more >> specifically the compiler used to initiate the build, not so much the >> target. Or is this aiming specifically for targets that only get >> cross-compilers and thus don't have stage 2 and haven't been tested with a >> C++ compiler yet? > >You are right that it is mainly an issue for the host. But some of >the target code gets only exposed when building for that target, and I >figured that the targets reported in gcc-testresults are tested in a >variety of hosts. Hence my call for help. I want to get as much >testing variety as possible. > >> For build issues with other compilers, 50167 and 50177 are still open (last >> time I looked, I couldn't find the meta-bug about switching to C++ in stage1 >> to add them as blockers). > >Thanks. I will take a look. If there is no meta bug, I'll create one. > > >Diego.
Re: RFH - Testing targets for the switch to C++
On 4/7/12 4:09 PM, Joel Sherrill wrote: For *-rtems* all test results are cross with tests run on simulators. We use a native compiler bulit from the same source for testing. Newlib is the C library and built at the same time. Do we need to enable any special flags from our existing configure? Just add --enable-build-with-cxx to the configure call. The C++ testing wiki page has full details. FWIW we have a few targets where the simulator is limited in memory and many tests fail. These get rejected because the mail message is too large. If someone is willing to help us trim things so the known failures get skipped, it would be appreciated. We would report more. :) Perhaps you could use the script contrib/testsuite-management/validate_failures.py? You can add those tests that are known to fail to a manifest file. It will then only report the failures that are not in that manifest. The only thing with this script is that it is not used by default by make check nor the testsuite reporting script. You'd have to call it from there. Thanks. Diego.
Re: RFC: -Wall by default
> "GDR" == Gabriel Dos Reis writes: GDR> Exactly. Our bugzilla databases has lot of requests in this spirit. If that is so, then defaulting to -Wall will just generate even more requests to turn that off. I find it hard to image that anyone who does any significant amount of compiling would fail to have their own CFLAGS (et al) with the options which they prefer. Forcing -Wall for those who did not ask for it is <...words.escape...>. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
On Sat, Apr 7, 2012 at 4:46 PM, James Cloos wrote: >> "GDR" == Gabriel Dos Reis writes: > > GDR> Exactly. Our bugzilla databases has lot of requests in this spirit. > > If that is so, then defaulting to -Wall will just generate even more > requests to turn that off. > > I find it hard to image that anyone who does any significant amount of > compiling would fail to have their own CFLAGS (et al) with the options > which they prefer. If all GCC users were forced to use the same development environment, that would be a plausible proposition that does not necessarily draw on limited imagination. > > Forcing -Wall for those who did not ask for it is <...words.escape...>. Thanks for your thoughtful opinion and contributions. -- Gaby
Re: RFC: -Wall by default
James Cloos writes: > GDR> Exactly. Our bugzilla databases has lot of requests in this spirit. > > If that is so, then defaulting to -Wall will just generate even more > requests to turn that off. You may well imagine. However, it isn't known. Turning it on by default, at least for a while is one way to replace such imagination with actual data... [Or, perhaps, not "-Wall" perse, but maybe a new option which is a little more conservative, "-Wstandard" or something...] -miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul.
Re: RFC: -Wall by default
On 05/04/2012 10:46, Gabriel Dos Reis wrote: > On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther > wrote: > >> Btw, it would be more reasonable to enable a subset of warnings that >> we enable at -Wall by default. > > Which ones for example? > > Here is a (partial) list: Your list seems a bit short, here's what today's trunk build says for -Wall: > -Waddress > -Warray-bounds (only with `-O2') > -Wc++11-compat > -Wchar-subscripts > -Wenum-compare (in C/Objc; this is on by default in C++) > -Wimplicit-int (C and Objective-C only) > -Wimplicit-function-declaration (C and Objective-C only) > -Wcomment > -Wformat > -Wmain (only for C/ObjC and unless `-ffreestanding') > -Wmaybe-uninitialized > -Wmissing-braces > -Wnonnull > -Wparentheses > -Wpointer-sign > -Wreorder > -Wreturn-type > -Wsequence-point > -Wsign-compare (only in C++) > -Wstrict-aliasing > -Wstrict-overflow=1 > -Wswitch > -Wtrigraphs > -Wuninitialized > -Wunknown-pragmas > -Wunused-function > -Wunused-label > -Wunused-value > -Wunused-variable > -Wvolatile-register-var IMHO we should move the -Wunused ones into -Wextra if we're going to turn on -Wall by default. The rest seem pretty reasonable defaults to me. cheers, DaveK
gcc-4.7-20120407 is now available
Snapshot gcc-4.7-20120407 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120407/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 186216 You'll find: gcc-4.7-20120407.tar.bz2 Complete GCC MD5=e44a8484687ef52c02066d6434ecf42b SHA1=a3fce129c19dfd1f10df1127d8aa7da218b7fdeb Diffs from 4.7-20120331 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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: RFC: -Wall by default
Dave Korn writes: > IMHO we should move the -Wunused ones into -Wextra if we're going to turn on > -Wall by default. The rest seem pretty reasonable defaults to me. How about instead adding new "-Wstandard", which will be on by default, and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for people that currently use -Wall). -miles -- "An atheist doesn't have to be someone who thinks he has a proof that there can't be a god. He only has to be someone who believes that the evidence on the God question is at a similar level to the evidence on the werewolf question." [John McCarthy]
Re: RFC: -Wall by default
On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote: > On 05/04/2012 10:46, Gabriel Dos Reis wrote: >> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther >> wrote: >> >>> Btw, it would be more reasonable to enable a subset of warnings that >>> we enable at -Wall by default. >> >> Which ones for example? >> >> Here is a (partial) list: > > Your list seems a bit short, here's what today's trunk build says for -Wall: Thank you Dave for the correction. > >> -Waddress >> -Warray-bounds (only with `-O2') >> -Wc++11-compat >> -Wchar-subscripts >> -Wenum-compare (in C/Objc; this is on by default in C++) >> -Wimplicit-int (C and Objective-C only) >> -Wimplicit-function-declaration (C and Objective-C only) >> -Wcomment >> -Wformat >> -Wmain (only for C/ObjC and unless `-ffreestanding') >> -Wmaybe-uninitialized >> -Wmissing-braces >> -Wnonnull >> -Wparentheses >> -Wpointer-sign >> -Wreorder >> -Wreturn-type >> -Wsequence-point >> -Wsign-compare (only in C++) >> -Wstrict-aliasing >> -Wstrict-overflow=1 >> -Wswitch >> -Wtrigraphs >> -Wuninitialized >> -Wunknown-pragmas >> -Wunused-function >> -Wunused-label >> -Wunused-value >> -Wunused-variable >> -Wvolatile-register-var > > IMHO we should move the -Wunused ones into -Wextra if we're going to turn on > -Wall by default. The rest seem pretty reasonable defaults to me. Even if we do not turn on -Wall by default, do you think we should have -Wunused in -Wall? -- Gaby
Re: RFC: -Wall by default
On Sat, Apr 7, 2012 at 5:57 PM, Miles Bader wrote: > Dave Korn writes: >> IMHO we should move the -Wunused ones into -Wextra if we're going to turn >> on >> -Wall by default. The rest seem pretty reasonable defaults to me. > > How about instead adding new "-Wstandard", which will be on by default, > and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for > people that currently use -Wall). In the end, a new option might probably be a good compromise even if I dislike the proliferation of options. Thanks, -- Gaby
Re: RFC: -Wall by default
On 4/7/2012 6:57 PM, Miles Bader wrote: Dave Korn writes: IMHO we should move the -Wunused ones into -Wextra if we're going to turn on -Wall by default. The rest seem pretty reasonable defaults to me. How about instead adding new "-Wstandard", which will be on by default, and keeping -Wall / -Wextra the same (so as to not _remove_ warnings for people that currently use -Wall). I think that's a good idea, then if -Wstandard generates complaints that can be fixed by rethinking inclusion of some options, that's easily fixed. -miles
