Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>,
	gdb-patches@sourceware.cygnus.com
Subject: Re: Hopefully my last request for 5.0 incorporation
Date: Wed, 19 Apr 2000 01:02:00 -0000	[thread overview]
Message-ID: <38FD673F.C5FFFAE4@cygnus.com> (raw)
In-Reply-To: <38F721D0.4CFF03E8@redhat.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7466 bytes --]

FYI,

I've applied the relevant patches to both the trunk and the 5.0 branch.

	Andrew

Fernando Nasser wrote:
> 
> For sake of reference by the others I will repeat here what is being proposed.
> 
> 1) Have "i r" stand for "info reg".  This used to work before but the addition of a new (much less
> frequently used) info command that also starts with "r" ("info remote-process") made it ambiguous.
> 
> "i r" is so much used that I am in favor of adding this one.  As I heard nothing to the contrary I
> will add it to gdb5.
> 
> 2) Have "maint i" stand for "maint info".  This also worked before but the addition of "maint
> internal-error" it does not work anymore.
> 
> I am quite concerned about adding alias that are so short.  However, "i" is an alias for the "info"
> command, and this is a very strong argument in favor of making it an alias for "info" under
> "maintenance".  After all "maintenance" is just a prefix that help us separate our "internal use
> only" (TM) commands from the normal user commands.
> 
> So, in this one exceptional case, due to the long term acceptance of "i" as short for "info", I will
> incorporate it.
> 
> But please folks, no more cryptic abrevs pls. ;-)
> 
> --
> Fernando Nasser
> Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ac131313@cygnus.com Wed Apr 19 01:31:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com, Ian Lance Taylor <ian@zembu.com>
Subject: Re: Problems with snapshot 20000412
Date: Wed, 19 Apr 2000 01:31:00 -0000
Message-id: <38FD6E92.8B94D0A0@cygnus.com>
References: <200004160807.EAA10378@indy.delorie.com> <38FD3F8C.B30CA4BF@cygnus.com> <200004190745.DAA14311@indy.delorie.com>
X-SW-Source: 2000-04/msg00375.html
Content-length: 1020

Eli Zaretskii wrote:
> 
> > It doesn't appear to affect the build
> 
> Really?  Did you try renaming your system-wide texinfo.tex (somewhere
> in the TeX installation tree)?

Hmm, ok, yes point taken :-)

> The special setting of TEXINPUTS before invoking TeX-related commands
> is there to make sure that the manual is produced using the specific
> version of texinfo.tex that was used by the maintainer(s), because
> another version of texinfo.tex might produce incorrect results or even
> fail.  If you have the same or compatible version of texinfo.tex in
> another place where TeX can find it, you won't see the problems caused
> by TEXINPUTS being set incorrectly.

Its already been reported:

http://sourceware.cygnus.com/ml/bug-automake/1999/msg00007.html

and the follow up:

http://sourceware.cygnus.com/ml/bug-automake/1999/msg00019.html

claims:

> > TEXINPUTS should be a list of directories.
> 
> Yup, this has been fixed in the CVS tree for quite some time.

I'll double check my automake tools.

	Andrew
From ac131313@cygnus.com Wed Apr 19 02:07:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: David Whedon <davidw@gordian.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Change configure.in so -W arnings match reality
Date: Wed, 19 Apr 2000 02:07:00 -0000
Message-id: <38FD76D9.A0975F97@cygnus.com>
References: <Pine.LNX.4.04.10004181444000.19907-100000@pcx08>
X-SW-Source: 2000-04/msg00376.html
Content-length: 2668

David Whedon wrote:
> 
> I'm building the gdb 5.0 branch on our sgi and it has a problem with the
> warning flags.
> 
> This error, I believe, is caused by this patch.
> ( http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00276.html )
> My problem would be fixed if -Wreturn-type is removed from gdb/configure.in
> (see the patch for more info)
> 
> I think it is because I am using an old gcc (October '99)

That isn't old.

	$ gcc --version
	2.7.2.3
	$ gcc -Wreturn-type hello.c
	hello.c:2: warning: return-type defaults to `int'

is old :-)  I'm actually slightly puzzled by this problem.  The
-Wreturn-type option is very old.

Anyway, I've applied the attached to the branch. But _not_ the trunk.

	Andrew
Wed Apr 19 18:05:24 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* configure.in (build_warnings): Default to warnings disabled.
	* configure: Re-generate.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.18.2.2
diff -p -r1.18.2.2 configure.in
*** configure.in	2000/04/14 10:40:00	1.18.2.2
--- configure.in	2000/04/19 08:59:55
*************** if test "${enable_netrom}" = "yes"; then
*** 482,489 ****
  fi
  
  
! build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
  -Wformat -Wparentheses -Wpointer-arith"
  # Not yet: -Wall -Wpointer-arith -Wstrict-prototypes
  # -Wmissing-prototypes -Wmissing-declarations
  AC_ARG_ENABLE(build-warnings,
--- 482,490 ----
  fi
  
  
! default_build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
  -Wformat -Wparentheses -Wpointer-arith"
+ build_warnings=""
  # Not yet: -Wall -Wpointer-arith -Wstrict-prototypes
  # -Wmissing-prototypes -Wmissing-declarations
  AC_ARG_ENABLE(build-warnings,
*************** AC_ARG_ENABLE(build-warnings,
*** 492,500 ****
    yes)	;;
    no)	build_warnings="-w";;
    ,*)   t=`echo "${enableval}" | sed -e "s/,/ /g"`
!         build_warnings="${build_warnings} ${t}";;
    *,)   t=`echo "${enableval}" | sed -e "s/,/ /g"`
!         build_warnings="${t} ${build_warnings}";;
    *)    build_warnings=`echo "${enableval}" | sed -e "s/,/ /g"`;;
  esac
  if test x"$silent" != x"yes" && test x"$build_warnings" != x""; then
--- 493,501 ----
    yes)	;;
    no)	build_warnings="-w";;
    ,*)   t=`echo "${enableval}" | sed -e "s/,/ /g"`
!         build_warnings="${default_build_warnings} ${t}";;
    *,)   t=`echo "${enableval}" | sed -e "s/,/ /g"`
!         build_warnings="${t} ${default_build_warnings}";;
    *)    build_warnings=`echo "${enableval}" | sed -e "s/,/ /g"`;;
  esac
  if test x"$silent" != x"yes" && test x"$build_warnings" != x""; then
From aoliva@cygnus.com Wed Apr 19 04:27:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch IEEE_FLOAT
Date: Wed, 19 Apr 2000 04:27:00 -0000
Message-id: <orln2atjnx.fsf@zecarneiro.lsd.ic.unicamp.br>
References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <np7le0lcjb.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00377.html
Content-length: 887

On Apr 14, 2000, Jim Blandy <jimb@zwingli.cygnus.com> wrote:

>> BTW, the need to add the below is going away soon.  I've pending
>> multi-arch patches that will provide this as a non- multi-arch default.
>> 
>> > + /* Provide a default value for IEEE_FLOAT.  */
>> > + #ifndef IEEE_FLOAT
>> > + #define IEEE_FLOAT (0)
>> > + #endif

> Sounds great to me!

BTW, are you aware that gdbarch.c fails to compile on a single-arch
build whose target header file doesn't define IEEE_FLOAT?  For
example, I've configured --target=mn10300-elf, and gdbarch.c won't
build because IEEE_FLOAT is not defined.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me


      reply	other threads:[~2000-04-19  1:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200004131903.VAA10696@reglos.regent.e-technik.tu-muenchen.de>
     [not found] ` <38F66D15.A68BBB52@cygnus.com>
2000-04-14  6:54   ` Fernando Nasser
2000-04-19  1:02     ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38FD673F.C5FFFAE4@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox