[Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_strtod.c]

Hi!

The problem was experienced by 5 persons at least.

How many persons is not very important, what important is how many
different compilers they used and how recent those are, in other words -
how frequently you could hit this bug in the wild. If it's just some
pre-release of Mandrake - then it's probably not that important. If it's
some widely used distro - then we'd better be on the safe side, just in
case, or at least put an error message into the code.

It was reported to happen with GCC 4.2.1..but is that recent enough?

4.2.1 prerelease as it seems. 4.1.2 doesn't seem to have this problem.
I'm not sure I have any machine with 4.2.1 around, but probably somebody
on the list does :)

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Nuno Lopes wrote:

I already expressed my opinion.. If you know what's the buggy gcc
version, just fail at configure time if it's present.

With a notice and reference to the bug number - so If people are stuck
with that compiler they can see a work around...

Regards
Alan

Nuno

Hi!

I wanted to ask people here about this patch. See history in
http://bugs.php.net/bug.php?id=43487 but basically there's some gcc out
there that miscompiles zend_strtod.c. We can fix it, probably at some
marginal performance cost, but the question is - should we? It's pre-release
compiler and not in the latest version.

So can anyone using non-prerelease gcc of any recent version - or non-gcc
compiler even - reproduce this? Should we keep the change or just tell
people "use working compiler"?

-------- Original Message --------
Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_strtod.c
Date: Sun, 27 Jul 2008 11:29:59 -0000
From: Dmitry Stogov dmitry@php.net
To: zend-engine-cvs@lists.php.net

dmitry Sun Jul 27 11:29:59 2008 UTC

Modified files:
/ZendEngine2 zend_strtod.c
Log:
Fix for bug #43487 (Wrong conversion of float to string)

http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_strtod.c?r1=1.37&r2=1.38&diff_format=u
Index: ZendEngine2/zend_strtod.c
diff -u ZendEngine2/zend_strtod.c:1.37 ZendEngine2/zend_strtod.c:1.38
--- ZendEngine2/zend_strtod.c:1.37 Wed Mar 26 14:23:02 2008
+++ ZendEngine2/zend_strtod.c Sun Jul 27 11:29:59 2008
@@ -89,7 +89,7 @@

• directly -- and assumed always to succeed.
  

*/

-/* $Id: zend_strtod.c,v 1.37 2008/03/26 14:23:02 scottmac Exp $ /
+/ $Id: zend_strtod.c,v 1.38 2008/07/27 11:29:59 dmitry Exp $ */

#include <zend.h>
#include <unicode/utypes.h>
@@ -991,9 +991,9 @@

static double ulp (double _x) /* {{{ */
{

•   _double x;
  

•   volatile _double x;
   register Long L;
  

•   _double a;
  

•   volatile _double a;
  
   value(x) = _x;
   L = (word0(x) & Exp_mask) - (P-1)*Exp_msk1;
  

@@ -1035,7 +1035,7 @@
{
ULong *xa, *xa0, w, y, z;
int k;

•   _double d;
  

•   volatile _double d;
  

#ifdef VAX
ULong d0, d1;
#else
@@ -1101,7 +1101,7 @@
Bigint *b;
int de, i, k;
ULong *x, y, z;

•   _double d;
  

•   volatile _double d;
  

#ifdef VAX
ULong d0, d1;
#endif
@@ -1223,7 +1223,7 @@

static double ratio (Bigint *a, Bigint b) / {{{ */
{

•   _double da, db;
  

•   volatile _double da, db;
   int k, ka, kb;
  
   value(da) = b2d(a, &ka);
  

@@ -1492,7 +1492,7 @@
Bigint *b, *b1, *delta, *mlo, *mhi, *S, *tmp;
double ds;
char *s, *s0;

•   _double d, d2, eps;
  

•   volatile _double d, d2, eps;
  
   value(d) = _d;
  

@@ -2056,7 +2056,7 @@
e, e1, esign, i, j, k, nd, nd0, nf, nz, nz0, sign;
CONST char *s, *s0, *s1;
double aadj, aadj1, adj;

•   _double rv, rv0;
  

•   volatile _double rv, rv0;
   Long L;
   ULong y, z;
   Bigint *bb, *bb1, *bd, *bd0, *bs, *delta, *tmp;
  

--
Zend Engine CVS Mailing List (http://cvs.php.net/)

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Nuno Lopes wrote:

I already expressed my opinion.. If you know what's the buggy gcc
version, just fail at configure time if it's present.

but with a test for the actual buggy behavior, not just
the gcc version i'd assume? (thing "regression" ;)

--
Hartmut Holzgraefe, MySQL Regional Support Manager EMEA

Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering