www.digitalmars.com         C & C++   DMDScript  

D.gnu - CTFE formatting of floating point values

reply Johannes Pfau <nospam example.com> writes:
I think this is a known issue:
DMD expects real.stringof to return a string in the %g format. However
the GCC function used for formatting real numbers always returns the %e
format.

There is a failing test for this in the test suite. (runnable/test42.d
(test49)). Would it be OK to disable this test if a file a bug
report on our bugtracker and on the gcc bugtracker? This would
allow running the other tests in that file.
Mar 25 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6788004dd00004d8c475d7
Content-Type: text/plain; charset=ISO-8859-1

On 25 March 2013 18:31, Johannes Pfau <nospam example.com> wrote:

 I think this is a known issue:
 DMD expects real.stringof to return a string in the %g format. However
 the GCC function used for formatting real numbers always returns the %e
 format.

 There is a failing test for this in the test suite. (runnable/test42.d
 (test49)). Would it be OK to disable this test if a file a bug
 report on our bugtracker and on the gcc bugtracker? This would
 allow running the other tests in that file.

GCC backend always appends the exponent, so I would just amend it to do: assert((25.5).stringof ~ (3.01).stringof == "2.55e+13.01e+0"); Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b6788004dd00004d8c475d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 5 March 2013 18:31, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:n= ospam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> I think this is a known issue:<br> DMD expects real.stringof to return a string in the %g format. However<br> the GCC function used for formatting real numbers always returns the %e<br> format.<br> <br> There is a failing test for this in the test suite. (runnable/test42.d<br> (test49)). Would it be OK to disable this test if a file a bug<br> report on our bugtracker and on the gcc bugtracker? This would<br> allow running the other tests in that file.<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">GCC backend alw= ays appends the exponent, so I would just amend it to do:<br><br>assert((25= .5).stringof ~ (3.01).stringof =3D=3D &quot;2.55e+13.01e+0&quot;);<br></div=

<br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#= 39;0&#39;; </div></div> --047d7b6788004dd00004d8c475d7--
Mar 25 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 25 Mar 2013 19:03:19 +0000
schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 25 March 2013 18:31, Johannes Pfau <nospam example.com> wrote:
 
 I think this is a known issue:
 DMD expects real.stringof to return a string in the %g format.
 However the GCC function used for formatting real numbers always
 returns the %e format.

 There is a failing test for this in the test suite.
 (runnable/test42.d (test49)). Would it be OK to disable this test
 if a file a bug report on our bugtracker and on the gcc bugtracker?
 This would allow running the other tests in that file.

GCC backend always appends the exponent, so I would just amend it to do: assert((25.5).stringof ~ (3.01).stringof == "2.55e+13.01e+0"); Regards

OK. I thought the .stringof format is somehow specified, but it seems it's not so this is indeed not a bug.
Mar 26 2013