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)));
next 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: linkBe 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).