Bug #81627 [Opn]: Incorrect result of php bitwise and with floats using clang13 -O2

From: Date: Wed, 17 Nov 2021 12:24:12 +0000
Subject: Bug #81627 [Opn]: Incorrect result of php bitwise and with floats using clang13 -O2
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-237806@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81627&edit=1 ID: 81627 Updated by: cmb@php.net Reported by: shaohua dot li at inf dot ethz dot ch Summary: Incorrect result of php bitwise and with floats using clang13 -O2 Status: Open Type: Bug Package: Scripting Engine problem Operating System: Ubuntu 20.04.3 LTS PHP Version: 8.1Git-2021-11-16 (Git) Block user comment: N Private report: N New Comment: The 32bit implementation of zend_dval_to_lval_slow() has an explicit comment[1] which says "we're going to make this number positive". I don't understand the reasoning, but apparently that is a deliberate design decision. Then again I don't understand why we don't saturate[2]. [1] <https://github.com/php/php-src/blob/php-7.4.26/Zend/zend_operators.c#L3261-L3262> [2] <https://github.com/php/php-src/commit/77566edbafb969e166239b3fbc929588c6630ee9> Previous Comments: ------------------------------------------------------------------------ [2021-11-17 11:32:36] cmb@php.net Casting very small floats to int may change the sign: <https://3v4l.org/Ku5YH>. I don't think this is particularly related to clang, nor to branch prediction, but the different behavior might rather be related to whether ZEND_DVAL_TO_LVAL_CAST_OK is defined or not[1]. If it is defined, we cast to zend_long, and for double values outside the range of zend_long, the behavior is undefined. On Windows, where ZEND_DVAL_TO_LVAL_CAST_OK is never defined, zend_dval_to_lval_slow()[2] yields an erroneous result anyway. [1] <https://github.com/php/php-src/blob/php-7.4.26/Zend/Zend.m4#L158-L187> [2] <https://github.com/php/php-src/blob/php-7.4.26/Zend/zend_operators.c#L3268-L3280> ------------------------------------------------------------------------ [2021-11-17 11:11:16] shaohua dot li at inf dot ethz dot ch Yes, I noticed the warning. I'm just worried that shouldn't all compilers/optimizations emit consistent results even if it's an error? I also tried gcc11 with -O0 and -O2, on which php emits the same results as clang13 -O2. ------------------------------------------------------------------------ [2021-11-17 10:32:20] requinix@php.net I assume you do *not* get the float-to-int deprecation warning when $n=58? PHP doesn't support bitwise AND with floats and will round them to ints, but that comes with branch prediction so -O2 may be running afoul of that. And that there is the limit of my knowledge on this matter. ------------------------------------------------------------------------ [2021-11-17 08:53:03] shaohua dot li at inf dot ethz dot ch Hi, Even if I decouple the two operations into two statements, the issue still exists. Also, for the robustness, correctness, and consistency of php, the outputs should be the same. Test script: ---------------- <?php function test() { $n = 0; $a = 0; while($a <= 0) { $a &= $a + $a; $a--; if (++$n > 59) die("bug\n"); } } test(); ?> ------------------------------------------------------------------------ [2021-11-16 23:24:03] requinix@php.net > $a &= $a-- + $a; That statements has two modifications to $a: the -- and the &=. PHP does not guarantee in what order those will happen. https://en.wikipedia.org/wiki/Sequence_point ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81627 -- Edit this bug report at https://bugs.php.net/bug.php?id=81627&edit=1

« previous php.bugs (#237806) next »