From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: aoliva@cygnus.com Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com Subject: Re: Configure libiberty after newlib Date: Thu, 18 May 2000 00:36:00 -0000 Message-id: <200005180736.DAA22028@indy.delorie.com> References: X-SW-Source: 2000-05/msg00287.html > From: Alexandre Oliva > Date: 17 May 2000 16:08:08 -0300 > > On May 16, 2000, Alexandre Oliva wrote: > > > * Makefile.in (configure-target-libiberty): Depend on > > configure-target-newlib. > > Having got approval from binutils and gdb maintainers (the latter in > private), I'm checking this in. How about release branches? I'd rather we do not change the release branch at this late stage. As far as I understand, GDB 5.0 is very close to a release, and we had better not rocked the boat too much with configury changes at this time. >From ac131313@cygnus.com Thu May 18 01:01:00 2000 From: Andrew Cagney To: GDB Patches Subject: gdb-4.95.2.tar.bz2 available Date: Thu, 18 May 2000 01:01:00 -0000 Message-id: <3923A2F2.302AEF0A@cygnus.com> X-SW-Source: 2000-05/msg00288.html Content-length: 333 FYI I have zero items in my 5.0 e-mail tray. Before unpacking this tar-ball, I would suggest renaming it to something obvious ;-) Assuming that no one screams, I have it renamed/moved to ftp.gnu.org/gnu/gdb some time after 2000-05-19.06:00 gmt Andrew PS: I need to figure out how to rename the gdb_4_95_2-*-release CVS tag :-) >From ac131313@cygnus.com Thu May 18 02:03:00 2000 From: Andrew Cagney To: GDB Patches Subject: -W* rules for engagement? Date: Thu, 18 May 2000 02:03:00 -0000 Message-id: <3923B19F.29591370@cygnus.com> X-SW-Source: 2000-05/msg00289.html Content-length: 2479 (The obvious follow on from PARAMS :-) How do people think we should attack this? I'm talking both from a logistic point of view of how should it be done and a philosophical view of position (w.r.t. warnings) should be taken. I can think of two extreme viewpoints: o fixing warnings is a waste of time. we've better things to do and besides we don't make mistakes. Go away. o GDB shall compile with -Wall -Wa-few-extras -Werror and emit no warnings. Drop everything and fix all warnings now. Add something to CVS so that it doesn't accept code containing warnings. The obvious flaw with the first (and yet highly convincing argument) is that people do make mistakes. A second and more significant problem is that code that contains ``warnings'' is, to a new developer, in an unknown state - was that if assignment ``if (x = y)'' intentional?. While not much of an problem in a small project with a single developer, it is a very big issue with a large long lived project with many developers (such as GDB). Being able to make a change to a file knowing that before/after it should contain no warnings is a real confidence booster to a developer. The reason I spent a significant amount of time last year expunging key warnings was so that I could, with a certain degree of confidence, make sweeping (but mechanical) changes across many files. The second proposal just needs a reality check. While some warning checks (e.g. -Wformat) have a relatively small over head and a very significant return others such as -Wunused-parameters (yes, GCC 3.0 does accept it!), I would argue, are of marginal benefit. In selecting warnings I think we need to be careful to choose those that avoid lots of false negatives. Further, given the vaguarities of operating systems it is also often the case that zero warnings are physically impossible. So what then? I'd like to suggest we pad out the current list of warnings: -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses -Wpointer-arith with a few additional key warnings such as -Wuninitialized -Wmissing-prototypes (any others?) and then try to get these down to zero so that -Werror can be used on this contracted list. Beyond that, people, can pursue things at their leisure. How to approach this? I'm easy. I am wary of fix warning a-thons and the like. Often fixing a warning involves a careful re-examination of the code. If someone wants to take it on, I'm again easy. Andrew >From kettenis@wins.uva.nl Thu May 18 03:27:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: -W* rules for engagement? Date: Thu, 18 May 2000 03:27:00 -0000 Message-id: <200005181027.MAA15469@landau.wins.uva.nl> References: <3923B19F.29591370@cygnus.com> X-SW-Source: 2000-05/msg00290.html Content-length: 1523 We should definitely try to eleminate all warnings from GDB. And indeed picking the right set of warning flags is important. Having a lot of spurious warnings makes it harder to spot the important ones (or even to spot errors, having Emacs walk through all the warnings before hitting the first real error can be quite annoying). So what then? I'd like to suggest we pad out the current list of warnings: -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses -Wpointer-arith Hmm, how important is -Wpointer-arith? It generates a lot of warnings from code in on Linux and the Hurd, due to a bug in gcc 2.95. For now I've just disabled it in my local CVS tree. with a few additional key warnings such as -Wuninitialized -Wmissing-prototypes (any others?) and then try to get these down to zero so that -Werror can be used on this contracted list. Beyond that, people, can pursue things at their leisure. How to approach this? I'm easy. I am wary of fix warning a-thons and the like. Often fixing a warning involves a careful re-examination of the code. If someone wants to take it on, I'm again easy. Enabling additional warnings one by one, giving people a few weeks to recover and fix things, is probably the best idea. The majority of those won't really involve a lot of re-examination of code. And the cases where it does, that code will probably benefit from a re-examination, at least if people will review, update and add comments to that code. Mark >From donnte@microsoft.com Thu May 18 09:42:00 2000 From: Donn Terry To: 'Andrew Cagney' , GDB Patches Subject: RE: -W* rules for engagement? Date: Thu, 18 May 2000 09:42:00 -0000 Message-id: <309F4FC4705DC844987051A517E9E39B16EEE4@red-pt-02.redmond.corp.microsoft.com> X-SW-Source: 2000-05/msg00291.html Content-length: 4275 Let me add a little on the side of fixing all warnings (over time): On a new port (or with a new compiler, or....) there is no way to know whether any given warning is benign or not. (Particularly since there is no canonical list of "expected" warnings.) To do a port right, each and every warning should be inspected to assure that it isn't significant on that particular port. That's an expensive proposition if there are any number of "too much trouble to fix" warnings. Also, if there are more than an easily memorized handful, the appearance of a new warning (which has a very good chance of being significant) due to a code change is much easier to miss. If it were my world :-) ... warnings would be acceptable, but each warning would require that in the source code there is a one page or longer (minimum acceptable size) explanation of why the warning is present, why it cannot be fixed, who made that decision, and a study of possible alternatives and why they were discarded. For the 1 warning in 100 that is easier to fix that way than to make a code change, it's probably justified to spend that effort. The rest would be fixed by code change real quickly :-) . To be more realistic: how about a goal that 5.1 has a minimum number of warnings, and provide a periodic scorecard on how it's going. (And maybe 1-line comments for the ones that are painful to fix any other way, so at least folks reviewing warnings know what to expect.) Donn > -----Original Message----- > From: Andrew Cagney [ mailto:ac131313@cygnus.com ] > Sent: Thursday, May 18, 2000 2:02 AM > To: GDB Patches > Subject: -W* rules for engagement? > > > (The obvious follow on from PARAMS :-) > > How do people think we should attack this? I'm talking both from a > logistic point of view of how should it be done and a > philosophical view > of position (w.r.t. warnings) should be taken. > > I can think of two extreme viewpoints: > > o fixing warnings is a waste of time. > we've better things to do and besides > we don't make mistakes. Go away. > > o GDB shall compile with > -Wall -Wa-few-extras -Werror > and emit no warnings. Drop > everything and fix all warnings > now. Add something to CVS so that > it doesn't accept code containing > warnings. > > The obvious flaw with the first (and yet highly convincing > argument) is > that people do make mistakes. A second and more significant > problem is > that code that contains ``warnings'' is, to a new developer, in an > unknown state - was that if assignment ``if (x = y)'' intentional?. > While not much of an problem in a small project with a single > developer, > it is a very big issue with a large long lived project with many > developers (such as GDB). Being able to make a change to a > file knowing > that before/after it should contain no warnings is a real confidence > booster to a developer. The reason I spent a significant > amount of time > last year expunging key warnings was so that I could, with a certain > degree of confidence, make sweeping (but mechanical) changes > across many > files. > > The second proposal just needs a reality check. While some warning > checks (e.g. -Wformat) have a relatively small over head and a very > significant return others such as -Wunused-parameters (yes, > GCC 3.0 does > accept it!), I would argue, are of marginal benefit. In selecting > warnings I think we need to be careful to choose those that avoid lots > of false negatives. Further, given the vaguarities of > operating systems > it is also often the case that zero warnings are physically > impossible. > > > So what then? I'd like to suggest we pad out the current list of > warnings: > > -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses > -Wpointer-arith > > with a few additional key warnings such as -Wuninitialized > -Wmissing-prototypes (any others?) and then try to get these down to > zero so that -Werror can be used on this contracted list. > Beyond that, > people, can pursue things at their leisure. > > How to approach this? I'm easy. I am wary of fix warning a-thons and > the like. Often fixing a warning involves a careful re-examination of > the code. If someone wants to take it on, I'm again easy. > > Andrew > >From assign@gnu.org Thu May 18 10:31:00 2000 From: assignments To: gdb-patches@sourceware.cygnus.com Subject: GDB assigns/disclaims Date: Thu, 18 May 2000 10:31:00 -0000 Message-id: <200005181731.NAA31164@delysid.gnu.org> X-SW-Source: 2000-05/msg00292.html Content-length: 1162 The following disclaimers and/or assignments concerning GDB have recently been added to the file copyright.list here at the Free Software Foundation. If you have any questions or corrections, please send them to my general work address, 3diff@gnu.org. Thanks! Brian Youmans Assignments Clerk GDB Christopher G. Demetriou US 1972 2000-04-26 Assigns past and future changes. cgd@sibyte.com GDB Ed Satterthwaite US 1943 2000-04-27 Assigns past and future changes. ehs@sibyte.com GDB Ralf Baechle Germany 1970 2000-04-22 Assigns past and future changes. ralf@gnu.org BINUTILS GDB GLIBC GCC SGI 2000-04-18 Disclaims changes by Ralf Ba:chle in the past and for the next 5 years. (Nancy Bigham) ANY BINUTILS GCC GDB Sibyte, Inc. 2000-04-26 Disclaims changes to free software by Ed Satterthwaite, in the past and for the next 2 years. (Leo Joseph) ANY BINUTILS GCC GDB Sibyte, Inc. 2000-04-26 Disclaims changes to free software by Chris G. Demetriou, in the past and for the next 2 years. (Leo Joseph) >From brolley@redhat.com Thu May 18 12:08:00 2000 From: Dave Brolley To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] Pass Machine to Assembler During Simulator Tests Date: Thu, 18 May 2000 12:08:00 -0000 Message-id: <39243FC9.6FA03C19@redhat.com> X-SW-Source: 2000-05/msg00293.html Content-length: 631 Hi, The test harness for the sim/testsuite/sim/ testsuite was correctly iterating through all of the requested machines, but was not passing this information to the assembler. As a result, the tests were really just running repeatedly for the default machine. This patch passes the machine information to the assembler using the -mcpu option. This information is then passed on to the linker and simulator via the obect file. I know that all assemblers do not have the -mcpu option, but the two targets using this framework (FR30 and m32r) both support it. Anyone have a better idea? If not, is this ok to commit? Dave >From aoliva@cygnus.com Thu May 18 13:21:00 2000 From: Alexandre Oliva To: gdb-patches@sourceware.cygnus.com Subject: mn10300 sim 64-bit clean-up Date: Thu, 18 May 2000 13:21:00 -0000 Message-id: X-SW-Source: 2000-05/msg00294.html Content-length: 127 This didn't kill as many testsuite failures on alpha-x-mn10300 as I had hoped it would, but it did kill some. Ok to install?