[llvm-bugs] [Bug 44188] New: Wrong optimization of byte-by-byte copying of long doubles

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44188

            Bug ID: 44188
           Summary: Wrong optimization of byte-by-byte copying of long
                    doubles
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ch3root at openwall.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Source code:

----------------------------------------------------------------------
#include <stdio.h>

int main()
{
    long double x = 1, y = 0;

    unsigned char *px = (unsigned char *)&x;
    unsigned char *py = (unsigned char *)&y;

    py[9] = px[9];
    py[8] = px[8];
    py[7] = px[7];
    py[6] = px[6];
    py[5] = px[5];
    py[4] = px[4];
    py[3] = px[3];
    py[2] = px[2];
    py[1] = px[1];
    py[0] = px[0];

    printf("y = %Lf\n", y);
}
----------------------------------------------------------------------

Results:

----------------------------------------------------------------------
$ clang -std=c11 -Weverything test.c && ./a.out
y = 1.000000
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
y = inf
----------------------------------------------------------------------

clang x86-64 version: clang version 10.0.0
(https://github.com/llvm/llvm-project.git
3f4b70c79e686117c2754d2c0a5a44c8b6829e79)


As I understand it, optimizer tracks the progress of assignments as actual long
double values and trips on intermediate results:
- initial x is 0xK3FFF8000000000000000;
- initial y is 0xK00000000000000000000;
- after copying one byte (py[9] = px[9];) y should be 0xK3F000000000000000000.
This is an unnormal (zero) and it's somehow changed to 0xK7FFF0000000000000000
(pseudo-infinity);
- final y is 0xK7FFF8000000000000000 (+infinity).
The problem is not that normalization of y went wrong. The problem is that,
during copying, the representation of y has changed outside of control of the
program.

And now the funny part -- DR 260[1] kinda blessed this behavior:

"
Committee Response

Question 1:

Values may have any bit-pattern that validly represents them and the
implementation is free to move between alternate representations (for example,
it may normalize pointers, floating-point representations etc.). In the case of
an indeterminate value all bit-patterns are valid representations and the
actual bit-pattern may change without direct action of the program. 
"

[1] http://open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

But IMO this shows that DR 260 Q1 is wrong, not that clang is right.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191130/fd9c4159/attachment.html>