[llvm-bugs] [Bug 43104] New: missed opt: restrict not propagated to definition

[via llvm-bugs]

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

            Bug ID: 43104
           Summary: missed opt: restrict not propagated to definition
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

The following code:

int foo(int* restrict x, int* restrict y);
int foo(int* x, int* y) { return *x + *y; }

C11 6.2.7p2 (https://port70.net/~nsz/c/c11/n1570.html#6.2.7p2) says:

> All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.

C11 6.7.6.3p15 (https://port70.net/~nsz/c/c11/n1570.html#6.7.6.3p15):

> For two function types to be compatible, [...] corresponding parameters shall have compatible types

C11 6.7.6.1p2 (https://port70.net/~nsz/c/c11/n1570.html#6.7.6.1p2) says:

> For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types.

so AFAICT this program has undefined behavior, because the prototypes are not
compatible, because their argument types are not compatible, because they are
pointer types that are differently cvr-qualified.

It isn't uncommon in C to give more work at the declarations in header files,
which is what most users of a library end up using, than to the implementation
of those declarations in a `.c` file. So we could propagate noalias to the
definition in this case. We should also propagate noalias from definitions to
function declarations for the opposite case, e.g., when the definition is
noalias, but the declaration is not. 

We have an incompatible type diagnostic that for some reason is a warning and
not an error, and that it doesn't warn on this case. I think we should also do
this, but if the declaration is in a different translation unit, such warnings
can only be emitted, e.g., during LTO.

-- 
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/20190824/d58216f9/attachment-0001.html>