[LLVMbugs] [Bug 20177] New: clang-cl doesn't accept a FOO(bar) in C mode

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20177

            Bug ID: 20177
           Summary: clang-cl doesn't accept a FOO(bar) in C mode
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ehsan at mozilla.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When I was trying to figure out why we can't build sctp
<https://code.google.com/p/sctp-refimpl/> on Windows.  Through an #include hell
chain, we get to code that looks pretty much like test.c below, and cl happily
accepts it (and it does so silently!)

$ cat test.c
FOO(bar);

$ cl -c test.c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c

$ clang-cl -c test.c
test.c(1,1) :  warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
FOO(bar);
^~~
test.c(1,5) :  error: a parameter list without types is only allowed in a
function definition
FOO(bar);
    ^
1 warning and 1 error generated.

(Note to self mostly, code in question:
https://code.google.com/p/sctp-refimpl/source/browse/trunk/KERN/userspace/user_src/user_include/user_socketvar.h#97)

I tried to figure out what MSVC makes out of this using the test case below,
and it seems like it considers FOO a function accepting one argument
(presumably an int) returning an int:

$ cat test.c
FOO(bar);

void f() { BAR(10); }

float FOO(bar, baz);

void g() { BAR(20, 30); }

int main() {
  f(); g();
  return 0;
}

$ cl test.c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
test.c(5) : warning C4142: benign redefinition of type
Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj
test.obj : error LNK2019: unresolved external symbol _BAR referenced in
function _f
test.exe : fatal error LNK1120: 1 unresolved externals

$ llvm-nm test.obj
00000000 N .debug$S
00000000 i .drectve
00000000 t .text
00ceee66 a @comp.id
80000191 a @feat.00
         U _BAR
00000000 T _f
00000010 T _g
00000030 T _main

But with some closer examination, it seems like MSVC treats this as a vararg
function effectively!

$ cat test.c
struct s{float m;} x;

FOO(bar);

void f() { BAR(x); }

float FOO(bar, baz);

void g() { BAR(20, x); }

int main() {
  f(); g();
  return 0;
}

$ cl test.c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
test.c(7) : warning C4142: benign redefinition of type
Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj
test.obj : error LNK2019: unresolved external symbol _BAR referenced in
function _f
test.exe : fatal error LNK1120: 1 unresolved externals

Should we support something like this in clang-cl?

-- 
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/20140701/f71669f8/attachment.html>