Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: testsuite/print_long_arg_list
  1999-04-08 15:41 ` testsuite/print_long_arg_list Stan Shebs
@ 1999-04-08 13:44   ` Stan Shebs
  1999-04-08 15:28   ` testsuite/print_long_arg_list J.T. Conklin
  1 sibling, 0 replies; 4+ messages in thread
From: Stan Shebs @ 1999-04-08 13:44 UTC (permalink / raw)
  To: phdm; +Cc: gdb-patches, gdb

   Date: Wed, 7 Apr 1999 18:49:38 +0200 (CEST)
   From: "Philippe De Muyter" <phdm@macqel.be>

   Running the testsuite with gdb-4.17.87 on m68k-motorola-sysv, I got
   (among others) the following failure :

   print_long_arg_list (a=22.219999999999998, b=33.332999999999998, c=0, d=-25, e=1
   [...]

   Looking at the expected result, I see :

       gdb_expect {
	   -re ".*print_long_arg_list \\(a=22.219999999999999, b=33.332999999999998
   [...]

   For me, the differences are in the last digits of some float or double numbers.
   Isn't the test too strict ?

I'm no floating-point expert, but I do know that you're supposed to be
careful about ignoring the last digit.  On the other hand, GDB just
uses a printf %g to display float values, so the output is going to
depend on the system's C library as much as GDB's correctness.  In fact,
"a" is actually 22.22 in the sources, so even the expected test result
isn't what it should be.

My inclination is to relax the match here.  What does everybody else
think?

							Stan


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: testsuite/print_long_arg_list
  1999-04-08 15:41 ` testsuite/print_long_arg_list Stan Shebs
  1999-04-08 13:44   ` testsuite/print_long_arg_list Stan Shebs
@ 1999-04-08 15:28   ` J.T. Conklin
  1999-04-08 16:01     ` testsuite/print_long_arg_list Stan Shebs
  1 sibling, 1 reply; 4+ messages in thread
From: J.T. Conklin @ 1999-04-08 15:28 UTC (permalink / raw)
  To: gdb-patches; +Cc: phdm, gdb

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I'm no floating-point expert, but I do know that you're supposed
Stan> to be careful about ignoring the last digit.  On the other hand,
Stan> GDB just uses a printf %g to display float values, so the output
Stan> is going to depend on the system's C library as much as GDB's
Stan> correctness.  In fact, "a" is actually 22.22 in the sources, so
Stan> even the expected test result isn't what it should be.

Stan> My inclination is to relax the match here.  What does everybody
Stan> else think?

Isn't the problem that 22.22 cannot be represented exactly in binary
floating point, thus is subject to various rounding issues in the
least significant digits?  Perhaps using values like 22.5, 22.25,
22.125, etc. would eliminate these problems.

	--jtc

-- 
J.T. Conklin
RedBack Networks


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: testsuite/print_long_arg_list
       [not found] <199904071649.SAA28333@mail.macqel.be>
@ 1999-04-08 15:41 ` Stan Shebs
  1999-04-08 13:44   ` testsuite/print_long_arg_list Stan Shebs
  1999-04-08 15:28   ` testsuite/print_long_arg_list J.T. Conklin
  0 siblings, 2 replies; 4+ messages in thread
From: Stan Shebs @ 1999-04-08 15:41 UTC (permalink / raw)
  To: phdm; +Cc: gdb-patches, gdb

   Date: Wed, 7 Apr 1999 18:49:38 +0200 (CEST)
   From: "Philippe De Muyter" <phdm@macqel.be>

   Running the testsuite with gdb-4.17.87 on m68k-motorola-sysv, I got
   (among others) the following failure :

   print_long_arg_list (a=22.219999999999998, b=33.332999999999998, c=0, d=-25, e=1
   [...]

   Looking at the expected result, I see :

       gdb_expect {
	   -re ".*print_long_arg_list \\(a=22.219999999999999, b=33.332999999999998
   [...]

   For me, the differences are in the last digits of some float or double numbers.
   Isn't the test too strict ?

I'm no floating-point expert, but I do know that you're supposed to be
careful about ignoring the last digit.  On the other hand, GDB just
uses a printf %g to display float values, so the output is going to
depend on the system's C library as much as GDB's correctness.  In fact,
"a" is actually 22.22 in the sources, so even the expected test result
isn't what it should be.

My inclination is to relax the match here.  What does everybody else
think?

							Stan
From jtc@redback.com Thu Apr 08 16:07:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@cygnus.com
Cc: phdm@macqel.be, gdb@cygnus.com
Subject: Re: testsuite/print_long_arg_list
Date: Thu, 08 Apr 1999 16:07:00 -0000
Message-id: <5mg16aycjf.fsf@jtc.redbacknetworks.com>
References: <199904082043.NAA29533@andros.cygnus.com>
X-SW-Source: 1999-04/msg00007.html
Content-length: 845

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I'm no floating-point expert, but I do know that you're supposed
Stan> to be careful about ignoring the last digit.  On the other hand,
Stan> GDB just uses a printf %g to display float values, so the output
Stan> is going to depend on the system's C library as much as GDB's
Stan> correctness.  In fact, "a" is actually 22.22 in the sources, so
Stan> even the expected test result isn't what it should be.

Stan> My inclination is to relax the match here.  What does everybody
Stan> else think?

Isn't the problem that 22.22 cannot be represented exactly in binary
floating point, thus is subject to various rounding issues in the
least significant digits?  Perhaps using values like 22.5, 22.25,
22.125, etc. would eliminate these problems.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Thu Apr 08 16:31:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@cygnus.com, phdm@macqel.be, gdb@cygnus.com
Subject: Re: testsuite/print_long_arg_list
Date: Thu, 08 Apr 1999 16:31:00 -0000
Message-id: <199904082301.QAA29767@andros.cygnus.com>
References: <5mg16aycjf.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-04/msg00008.html
Content-length: 537

   From: jtc@redback.com (J.T. Conklin)
   Date: 08 Apr 1999 15:26:12 -0700

   Isn't the problem that 22.22 cannot be represented exactly in binary
   floating point, thus is subject to various rounding issues in the
   least significant digits?  Perhaps using values like 22.5, 22.25,
   22.125, etc. would eliminate these problems.

Doh!  I should've thought of that!  Yes, that does give better
results, and the author of those tests, who is on this list, says
"change 'em however you want".  So that's what will happen.  Thanks! -s
From sandra18572@mci.net Fri Apr 09 02:39:00 1999
From: "sandra18572@mci.net" <sandra18572@mci.net>
To: egcs@cygnus.com
Subject: Hidden Showercam ;-) (147)
Date: Fri, 09 Apr 1999 02:39:00 -0000
Message-id: <9673.89295@mx10.mindspring.com>
X-SW-Source: 1999-04/msg00009.html
Content-length: 198

Watch our hot horny girls in action via live webcam feeds!

FREE PREVIEW - - - The best xxx to hit the net guaranteed!

http://205.134.178.3/free_stuff/~girlie/index.html
*********************
3921
From fortinj@ibm.net Fri Apr 09 09:25:00 1999
From: John Fortin <fortinj@ibm.net>
To: gdb <gdb@cygnus.com>
Subject: Windows threads, gdb, and cygwin
Date: Fri, 09 Apr 1999 09:25:00 -0000
Message-id: <370E16B9.6EBB5294@ibm.net>
X-SW-Source: 1999-04/msg00010.html
Content-length: 545

All,
    I compiled the newest snapshot of gdb using cygwin ( after fighting
with the configuration.  Doesn't seem to work well recursively. )

Chris Faylor had indicated that win32 threads were now supported.  When
I executed gdb with a threaded program,  'info threads' returns
nothing.  Documentation I read indicates that this means thread
functions are unavailable.

Is win32 native threads supported?

I am adding pthread functions to cygwin and would like to debug the
resulting thread functions.

Thanks,
John Fortin
fortinj@ibm.net





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: testsuite/print_long_arg_list
  1999-04-08 15:28   ` testsuite/print_long_arg_list J.T. Conklin
@ 1999-04-08 16:01     ` Stan Shebs
  0 siblings, 0 replies; 4+ messages in thread
From: Stan Shebs @ 1999-04-08 16:01 UTC (permalink / raw)
  To: jtc; +Cc: gdb-patches, phdm, gdb

   From: jtc@redback.com (J.T. Conklin)
   Date: 08 Apr 1999 15:26:12 -0700

   Isn't the problem that 22.22 cannot be represented exactly in binary
   floating point, thus is subject to various rounding issues in the
   least significant digits?  Perhaps using values like 22.5, 22.25,
   22.125, etc. would eliminate these problems.

Doh!  I should've thought of that!  Yes, that does give better
results, and the author of those tests, who is on this list, says
"change 'em however you want".  So that's what will happen.  Thanks! -s


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1999-04-08 16:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <199904071649.SAA28333@mail.macqel.be>
1999-04-08 15:41 ` testsuite/print_long_arg_list Stan Shebs
1999-04-08 13:44   ` testsuite/print_long_arg_list Stan Shebs
1999-04-08 15:28   ` testsuite/print_long_arg_list J.T. Conklin
1999-04-08 16:01     ` testsuite/print_long_arg_list Stan Shebs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox