[llvm-bugs] [Bug 33063] New: -O2 code miscompilation starting in clang 3.9 (still in 4.0.1rc1)

[via llvm-bugs]

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

            Bug ID: 33063
           Summary: -O2 code miscompilation starting in clang 3.9 (still
                    in 4.0.1rc1)
           Product: clang
           Version: 3.9
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: terry-llvm at glaver.org
                CC: llvm-bugs at lists.llvm.org

Created attachment 18451
  --> https://bugs.llvm.org/attachment.cgi?id=18451&action=edit
Complete program to reproduce the bug

It appears that clang 3.9.1 is generating incorrect code when compiling the
attached example program (extracted from a much larger project written by dmr
many years ago) with optimization greater than -O0. 3.8.1 generates working
code at all of -O0 -O1 and -O2. I have not tried versions > 3.8.1 and < 3.9.1,
so I can't pin it down more definitively. 3.9.1 generates working code at -O0,
returns an incorrect numerical result at -O1, and returns nan at -O2 and -O3.
4.0.1rc1 behaves the same as 3.9.1. A relatively recent version of gcc (4.8.4)
also compiles the program correctly at -O2. The problem was reproduced on a
Linux system with different hardware, so it doesn't seem to be a
system-specific issue. All of the following tests were performed on: 

FreeBSD pool20.dom.ain 11.0-STABLE FreeBSD 11.0-STABLE #0 r318279: Sun May 14
 16:26:06 EDT 2017     root at pool20:/usr/obj/usr/src/sys/GENERIC  amd64

Here is the result of compilation / testing at -O1, -O2, and -O3 with 3.8.1 and
3.9.1:

Script started on Tue May 16 17:24:37 2017
(0:2) pool20:/sysprog/terry# clang38 -g -Wall -O0 -o single single.c -lm
(0:3) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = 2.676092
(0:4) pool20:/sysprog/terry# clang38 -g -Wall -O1 -o single single.c -lm
(0:5) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = 2.676092
(0:6) pool20:/sysprog/terry# clang38 -g -Wall -O2 -o single single.c -lm
(0:7) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = 2.676092
(0:8) pool20:/sysprog/terry# clang39 -g -Wall -O0 -o single single.c -lm
(0:9) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = 2.676092
(0:10) pool20:/sysprog/terry# clang39 -g -Wall -O1 -o single single.c -lm
(0:11) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = 9.653773
(0:12) pool20:/sysprog/terry# clang39 -g -Wall -O2 -o single single.c -lm
(0:13) pool20:/sysprog/terry# ./single
pturbl (before) = -0.171976
q0 = 3063.745875, -v0 = -1202.450010
pturbl (after) = nan
(0:14) pool20:/sysprog/terry# exit
Script done on Tue May 16 17:25:38 2017

The expected answer is 2.676092. As you can see, that happens in all but the
3.9.1 -O1 and -O2 tests.

The function in question is:

double
cosadd(int n, double coef, ...)
{
        double *coefp;
        char *cp;
        int i;
        double sum, a1, a2;

        sum = 0;
        cp = cacp;

loop:
        a1 = *cafp++;
        if(a1 == 0) {
                cacp = cp;
                return sum;
        }
        a2 = *cafp++;
        i = n;
        coefp = &coef;
        do
                a2 += *cp++ * *coefp++;
        while(--i);
        sum += a1 * cos(a2);
        goto loop;
}

Which is copied verbatim from dmr's source. While ugly, it passes -Wall. It
dates from the same era as dmr's famous "You are not expected to understand
this" comment.

I am attaching the complete program needed to reproduce this. If more
information is needed, just let me know.

-- 
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/20170516/745ab212/attachment.html>