[llvm-bugs] [Bug 44373] New: Optimization with `restrict`: is `p == q ? p : q` "based" on `p`?

[via llvm-bugs]

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

            Bug ID: 44373
           Summary: Optimization with `restrict`: is `p == q ? p : q`
                    "based" on `p`?
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          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

The question: is `p == q ? p : q` "based" on `p`? The definition of "based" is
like this (C11, 6.7.3.1p3):

"In what follows, a pointer expression E is said to be based on object P if (at
some sequence point in the execution of B prior to the evaluation of E)
modifying P to point to a copy of the array object into which it formerly
pointed would change the value of E."

First, suppose that the answer is "yes". Then the following program should be
strictly conforming and should always print "2":

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

static int f(int *restrict p, int *restrict q)
{
    *p = 1;

    int *r;
    if (p == q) {
        r = p;
    } else {
        r = q;
    }

    // is r "based" on p?

    *r = 2;

    return *p;
}

int main()
{
    int x;
    printf("%d\n", f(&x, &x));
}
----------------------------------------------------------------------
$ clang -std=c11 -Weverything test.c && ./a.out
2
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
1
----------------------------------------------------------------------
clang x86-64 version: clang version 10.0.0
(https://github.com/llvm/llvm-project.git
fccac1ec16951e9a9811abf19e2c18be147854fc)
----------------------------------------------------------------------

Ok, fair enough, `p == q ? p : q` is always equal to `q`, doesn't change when
`p` changes and, thus, is not "based" on `p`.
Then the following program (4 differences are marked) should be fine according
to the standard and should always print "2":

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

static int f(int *restrict p, int *restrict q)
{
    *q = 1; // 1) changed p -> q

    int *r;
    if (p == q) {
        r = p;
    } else {
        r = q;
        printf("branch not taken"); // 2) added this
    }

    // is r "based" on p?

    if (p == q) // 3) added if
        *r = 2;

    return *q; // 4) changed p -> q
}

int main()
{
    int x;
    printf("%d\n", f(&x, &x));
}
----------------------------------------------------------------------
$ clang -std=c11 -Weverything test.c && ./a.out
2
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
1
----------------------------------------------------------------------
clang x86-64 version: clang version 10.0.0
(https://github.com/llvm/llvm-project.git
fccac1ec16951e9a9811abf19e2c18be147854fc)
----------------------------------------------------------------------

Either way, there is a problem...

Despite the gut instinct, equal restricted pointers are fine per se -- see,
e.g., Example 3 in C11, 6.7.3.1p10.

gcc bug -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92963.

-- 
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/20191224/861d8b45/attachment.html>