[llvm-bugs] [Bug 40218] New: clang-cl not handling comparison of function pointer to that of its alternatename

[via llvm-bugs]

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

            Bug ID: 40218
           Summary: clang-cl not handling comparison of function pointer
                    to that of its alternatename
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: metzman at google.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    nicolasweber at gmx.de, richard-llvm at metafoo.co.uk,
                    rnk at google.com

Created attachment 21291
  --> https://bugs.llvm.org/attachment.cgi?id=21291&action=edit
Reproducing test case

Given the file repro.c (also attached):

```
#include <stdio.h>
#include <stdlib.h>

typedef void (*LfiPtr)(int x);

void LfiDef(int x) {}

__pragma(comment(linker, "/alternatename:Lfi=LfiDef")) void Lfi(int x);

int main() {
  printf("void* Fun: %p, FunDef: %p\n", (void*) Lfi, (void*) LfiDef);
  if (Lfi == LfiDef) {
    puts("WORKING");
    return 0;
  }
  puts("BROKEN");
  return 1;
}
```

When I compile repro.c with clang-cl run it, I get this output:

```

> bin\clang-cl.exe repro.c -o clang-repro & clang-repro.exe
Lfi: 00007FF7D4A31000, LfiDef: 00007FF7D4A31000
BROKEN

```

This behavior seems incorrect to me. Lfi and LfiDef have the same value
(00007FF7D4A31000) according to the print statement and my understanding of
alternatename, but the comparison Lfi == LfiDef is false. It should be true.

cl.exe seems to produce the correct behavior though.
When I compile repro.c with cl and run the binary, I get this output:

```

> rm repro.exe & cl.exe repro.c & repro.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26433 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

repro.c
Microsoft (R) Incremental Linker Version 14.14.26433.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj
Lfi: 00007FF728461000, LfiDef: 00007FF728461000
WORKING

```

Back when I had a less minimal reproducer and the comparison was done in
another function, the optimization level seemed to affect things, with -O0
causing the correct behavior, but in this example that doesn't seem to be the
case.

I'm using a clang-cl built from trunk (rL350342) with cl.exe and these CMake
arguments (from stage 1 of clang-x64-ninja-win7).
cmake -GNinja C:\src\llvm\llvm -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=True -DLLVM_LIT_ARGS="-v" -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS="compiler-rt;clang;lld" 

I don't think my compiler is broken otherwise because when I run check-all, the
only two tests I fail are the same that fail on the builder right now
(http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/14891)

-- 
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/20190103/786c9ff1/attachment.html>