home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / gnu / g / lib / bug / 718 < prev    next >
Encoding:
Text File  |  1992-12-22  |  4.3 KB  |  98 lines

  1. Newsgroups: gnu.g++.lib.bug
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu!watson.ibm.com!c$dje
  3. From: c$dje@watson.ibm.com (David Edelsohn)
  4. Subject: Re: libg++-2.3 build problems under AIX-3.2
  5. Message-ID: <9212222231.AA04988@tweetie.watson.ibm.com>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: GNUs Not Usenet
  8. Distribution: gnu
  9. Date: Tue, 22 Dec 1992 22:31:31 GMT
  10. Approved: bug-lib-g++@prep.ai.mit.edu
  11. Lines: 85
  12.  
  13.     [Possible gcc backend bug for RS/6000 architecture.  libg++-2.3
  14. does not pass its self-tests (make check) and calls abort because of assert
  15. in tFile.C:t11().]
  16.  
  17.     I have tracked down the bug in formatted I/O further by comparing
  18. the steps that the Sun version takes versus the RS/6000 version.  For
  19. t11(), cout.form(...), the Sun version calls __outfloat() from
  20. streambuf::vform() with precision=2 and fill=' ' while the RS/6000 version
  21. uses precision=6 and fill=GARBAGE.  fill is set correctly before the call
  22. but is corrupted in the call itself (it is wrong in the called subroutine
  23. itself so this presumably is not a gdb-4.7 bug).  precision is set
  24. differently because the Sun and RS/6000 take slightly different paths
  25. through the code for the '.' case of the format.  The Sun executes:
  26.  
  27.  
  28.                         while (is_digit(ch)) {
  29.                                 n = 10 * n + to_digit(ch);
  30.                                 ch = *fmt++;
  31.                         }
  32.  
  33. but the RS/6000 skips that fragment and proceeds directly to:
  34.  
  35.                         prec = n < 0 ? -1 : n;
  36.                         goto reswitch;
  37.  
  38. so that it ignores the precision specification.  This appears to be an
  39. error in the generated code.  I have not tried to check the assembly output
  40. itself.  As I stated in the original report, I am using gcc-2.3.2 for both
  41. the Sun and RS/6000 tests.  gdb call and traceback information follows.
  42.  
  43.                     David
  44. (Disclaimer: I do not speak for IBM and it does not speak for me.)
  45.  
  46.     Sun call and traceback:
  47.  
  48. __outfloat (value=5.5, sb=0xf7fff150, type=102, width=0, precision=2, flags=0,
  49.     sign_mode=0 '\000', fill=32 ' ') at outfloat.C:31
  50. 31          int count = 0;
  51. (gdb) where
  52. #0  __outfloat (value=5.5, sb=0xf7fff150, type=102, width=0, precision=2,
  53.     flags=0, sign_mode=0 '\000', fill=32 ' ') at outfloat.C:31
  54. #1  0xb8d8 in streambuf::vform (this=0xf7fff150, fmt0=0x0,
  55.     ap=0xf7fff90c "@\031") at sbufvform.C:339
  56. #2  0xb40c in help_vform (sb=0x1a9a4, fmt0=0x4fb0 "%.2f+%.2f = %4.3e\n%n",
  57.     ap=0xf7fff904 "@\026") at sbufvform.C:86
  58. #3  0xb4bc in streambuf::vform (this=0x1a9a4,
  59.     fmt0=0x4fb0 "%.2f+%.2f = %4.3e\n%n", ap=0xf7fff904 "@\026")
  60.     at sbufvform.C:200
  61. #4  0xa6dc in ostream::form (this=0x1a3bc,
  62.     format=0x4fb0 "%.2f+%.2f = %4.3e\n%n") at iostream.C:638
  63. #5  0x5060 in t11 () at tFile.C:423
  64. #6  0x52e0 in main (argc=0, argv=0xf7fffa34) at tFile.C:460
  65. (gdb)
  66.  
  67.     RS/6000 call and traceback:
  68.  
  69. __outfloat (value=5.5, sb=0x2ff7f778, type=102 'f', width=0, precision=6,
  70.     flags=0, sign_mode=0 '\000', fill=536870912) at outfloat.C:31
  71. 31          int count = 0;
  72. (gdb) where
  73. #0  __outfloat (value=5.5, sb=0x2ff7f778, type=102 'f', width=0, precision=6,
  74.     flags=0, sign_mode=0 '\000', fill=536870912) at outfloat.C:31
  75. #1  0x10013270 in streambuf::vform (this=<unknown struct>,
  76.     fmt0=0x10018a58 "%.2f+%.2f = %4.3e\n%n", ap=0x2ff7fa28 "@\031")
  77.     at sbufvform.C:339
  78. #2  0x10012e1c in help_vform (sb=<unknown struct>,
  79.     fmt0=0x10018a58 "%.2f+%.2f = %4.3e\n%n", ap=0x2ff7fa20 "@\026")
  80.     at sbufvform.C:86
  81. #3  0x10012eac in streambuf::vform (this=<unknown struct>,
  82.     fmt0=0x10018a58 "%.2f+%.2f = %4.3e\n%n", ap=0x2ff7fa20 "@\026")
  83.     at sbufvform.C:200
  84. #4  0x10006ed4 in ostream::form (this=0x20051fa4,
  85.     format=0x10018a58 "%.2f+%.2f = %4.3e\n%n") at streambuf.h:5
  86. #5  0x10002a6c in t11 () at tFile.C:423
  87. #6  0x10002c80 in main (argc=1, argv=0x2ff7faf0) at tFile.C:460
  88. #7  0x1000042c in __start ()
  89. (gdb)
  90. ===============================================================================
  91. David Edelsohn                                      T.J. Watson Research Center
  92. c$dje@watson.ibm.com                                P.O. Box 218
  93. +1 914 945 3011 (Tieline 862)                       Yorktown Heights, NY 10598
  94. "The Church doesn't have problems with sex; the world does" -- Vatican official
  95. "A good theory should fit on a T-shirt" -- Astronomer at Jan 1992 AAS meeting
  96.  
  97.  
  98.