public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Jim Wilson <wilson@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: debug/1621: Debugging with complex numbers
Date: Wed, 11 Dec 2002 16:16:00 -0000	[thread overview]
Message-ID: <20021212001601.19684.qmail@sources.redhat.com> (raw)

The following reply was made to PR debug/1621; it has been noted by GNATS.

From: Jim Wilson <wilson@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Wolfgang Bangerth <bangerth@ticam.utexas.edu>,
   "Joseph S. Myers" <jsm28@cam.ac.uk>, bangerth@dealii.org,
   gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: debug/1621: Debugging with complex numbers
Date: 11 Dec 2002 19:05:47 -0500

 About the $imag, $real stuff in the gcc/doc/extend.texi file...
 The part about "None of the supported debug info formats..." is obsolete.
 DWARF2 location descriptions can handle this easily, and this is already
 supported in dwarf2out.c.  Perhaps also DWARF, but I don't care enough to look
 it up.  The stabs hack of emitting two foo$imag and foo$real symbols is ugly
 and should be discouraged.  I don't think it makes any sense to teach gdb
 about this hack.  We should instead encourage use of DWARF2, which we are
 already doing.
 
 I tried writing a patch to make gcc use the Solaris 'R' stab letter extension.
 
 This brings up a number of questions.  Sun only defined 3 float and 3 complex
 float types.  However, we have 7 float types and 6 complex float types.  (They
 should be the same, but that is a different problem.)  Do we extend the
 Solaris extension to meet our needs?  Or fall back on the problematic 'r'
 letter when we can't use 'R'?  Extending 'R' might make us incompatible with
 Sun if in the future Sun extends it too, so trying to discuss it with Sun is
 a good idea.  Or perhaps invent our own similar extension that won't conflict
 with Sun?
 
 Also, there is the issue of IEEE versus non-IEEE types.  These types as
 defined are supposed to be for IEEE FP types only.  We support a number of
 non-IEEE fp types.  Do we use the same type number for both?  Or do we add
 even more type numbers for non-IEEE types?
 
 Here is a provisional gcc patch that makes Joseph Myers 4 tests work.
 
 The IEEE vs non-IEEE problem can be ignored for now.  However, the issue of
 handling non-standard float types can't be, because as written the patch
 will abort for targets using non-standard float types.
 
 2002-12-11  Jim Wilson  <wilson@redhat.com>
 
 	* dbxout.c (dbxout_fptype_value): New.
 	(dbxout_type, case COMPLEX_TYPE): Call it.  Use 'R' instead of 'r'.
 
 Index: dbxout.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/dbxout.c,v
 retrieving revision 1.129
 diff -p -r1.129 dbxout.c
 *** dbxout.c	8 Nov 2002 23:12:24 -0000	1.129
 --- dbxout.c	12 Dec 2002 00:01:20 -0000
 *************** static void dbxout_finish		PARAMS ((cons
 *** 294,299 ****
 --- 294,300 ----
   static void dbxout_start_source_file	PARAMS ((unsigned, const char *));
   static void dbxout_end_source_file	PARAMS ((unsigned));
   static void dbxout_typedefs		PARAMS ((tree));
 + static void dbxout_fptype_value		PARAMS ((tree));
   static void dbxout_type_index		PARAMS ((tree));
   #if DBX_CONTIN_LENGTH > 0
   static void dbxout_continue		PARAMS ((void));
 *************** dbxout_finish (filename)
 *** 689,694 ****
 --- 690,738 ----
   #endif /* DBX_OUTPUT_MAIN_SOURCE_FILE_END */
   }
   
 + /* Output floating point type values used by the 'R' stab letter.
 +    These numbers come from include/aout/stab_gnu.h in binutils/gdb.  */
 + 
 + /* ??? These are supposed to be IEEE types, but we don't check for that.
 +    We could perhaps add additional numbers for non-IEEE types if we need
 +    them.  */
 + 
 + static void
 + dbxout_fptype_value (type)
 +      tree type;
 + {
 +   char value = '0';
 +   enum machine_mode mode = TYPE_MODE (type);
 + 
 +   if (TREE_CODE (type) == REAL_TYPE)
 +     {
 +       if (mode == SFmode)
 + 	value = '1';
 +       else if (mode == DFmode)
 + 	value = '2';
 +       else if (mode == TFmode || mode == XFmode)
 + 	value = '6';
 +       else
 + 	abort ();
 +     }
 +   else if (TREE_CODE (type) == COMPLEX_TYPE)
 +     {
 +       if (mode == SCmode)
 + 	value = '3';
 +       else if (mode == DCmode)
 + 	value = '4';
 +       else if (mode == TCmode || mode == XCmode)
 + 	value = '5';
 +       else
 + 	abort ();
 +     }
 +   else
 +     abort ();
 + 
 +   putc (value, asmfile);
 +   CHARS (1);
 + }
 + 
   /* Output the index of a type.  */
   
   static void
 *************** dbxout_type (type, full)
 *** 1362,1370 ****
   
         if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE)
   	{
 ! 	  fprintf (asmfile, "r");
   	  CHARS (1);
 ! 	  dbxout_type_index (type);
   	  putc (';', asmfile);
   	  CHARS (1);
   	  print_wide_int (2 * int_size_in_bytes (TREE_TYPE (type)));
 --- 1406,1414 ----
   
         if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE)
   	{
 ! 	  putc ('R', asmfile);
   	  CHARS (1);
 ! 	  dbxout_fptype_value (type);
   	  putc (';', asmfile);
   	  CHARS (1);
   	  print_wide_int (2 * int_size_in_bytes (TREE_TYPE (type)));


             reply	other threads:[~2002-12-12  0:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-11 16:16 Jim Wilson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-28 10:59 jsm28
2002-12-13 11:26 Joseph S. Myers
2002-12-13  9:32 wilson
2002-12-12 14:16 Jim Wilson
2002-12-12 13:36 Jim Wilson
2002-12-12 11:56 Daniel Jacobowitz
2002-12-12  7:56 Jim Wilson
2002-12-11 17:26 Daniel Jacobowitz
2002-12-09 12:24 bangerth
2002-12-07 17:26 Daniel Jacobowitz
2002-12-05 16:16 Wolfgang Bangerth
2002-12-05 15:26 Joseph S. Myers
2002-12-05 12:09 bangerth
2001-04-01  0:00 Joseph Myers

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=20021212001601.19684.qmail@sources.redhat.com \
    --to=wilson@redhat.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).